One place the policy lives
The rule that decides who gets onboarded is a flow, not a settlement between three vendor dashboards and a script.
Onboarding and KYC
Identity, document, business and sanctions checks orchestrated as one flow — so most applicants clear automatically and the rest reach a reviewer with the file already assembled.
The problem
Most onboarding stacks are a chain of vendor calls with a person at the end reading the results. Each vendor answers its own narrow question well; none of them answers yours, which is whether to open the account.
So the decision logic ends up in three places at once — some in a vendor's dashboard, some in glue code, some in a reviewer's head — and the onboarding funnel gets slower every time a new requirement lands, because nobody can see the whole rule.
What the flow looks like
Person or business, against a schema you define, so the flow fails loudly on a missing field instead of quietly onboarding on incomplete data.
An individual and a company need different checks. One flow, two explicit paths, rather than two systems that drift apart.
Identity, document, business registry and sanctions providers, called with your credentials and your thresholds.
What a pass, a partial match and a hard fail mean for your risk appetite — written where your compliance team can read it, not inside a vendor console.
One table mapping the combination of check outcomes to an onboarding decision, with a row for every combination you accept.
Keep the verified identity and its checks as an entity, so a later decision does not start from nothing.
Partial matches and edge cases become a case with the evidence attached, for a compliance reviewer to close.
Accept, refer or reject, with the checks that produced it and the version of the policy that was in force.
Data you can pull in
A Connection node calls the providers you already pay for, with your credentials. ArboRule decides which calls to make and what the answers mean together — it does not resell the data or sit between you and your vendor.
What changes
The rule that decides who gets onboarded is a flow, not a settlement between three vendor dashboards and a script.
Clear-cut applicants finish automatically. A reviewer's queue holds the cases that genuinely need judgment, with the checks already attached.
Every onboarding decision keeps the checks that ran, the results, the policy version and the path taken — the file a regulator asks for, produced by the run itself.
Questions
No. It orchestrates them. You keep your contracts with identity, document, business-registry and sanctions providers; the flow decides which checks to run, in what order, and what their combined result means for your risk appetite.
Yes. A Split node branches on applicant type, so an individual and a company follow different check paths inside one flow — which keeps a single policy visible instead of two systems that drift apart.
Whatever your policy says, written explicitly. Typically the flow opens a case for a compliance reviewer with the match evidence attached and returns a referral, rather than forcing a binary accept or reject on an ambiguous result.
Ready when you are
Build the flow in Sandbox, run your own cases through it, and see the trace before anything reaches a customer.