Assembling the onboarding evidence, and leaving the decision with the officer who owns it
Onboarding a customer is not one check but several, run by different people against different sources, and the file usually gets assembled twice — once to open the account and again when someone asks how it was opened. The evidence ends up spread across a document store, a screening tool and somebody's mailbox. Run as one orchestrated process, the file is assembled once: identity, ownership and screening gathered in one place with every finding cited to its source, and a risk rating proposed against the institution's own rules. The officer the policy names still makes the decision, and the design gives an agent no way to make it for them.
A reference architecture: how RoboAgentix would model this process on UiPath. It is not a description of a delivered project, and no client, result or metric is implied.
What starts it
An account-opening application arrives from a branch, an online form, or a relationship manager submitting on the applicant's behalf.
Why it is orchestrated rather than scripted
- Registry extracts and screening responses come back at different times, and the process has to hold the file open rather than close it on what happened to arrive first.
- Which cases are reserved to a person changes with regulation, product and jurisdiction, and belongs in one decision table the compliance function edits rather than inside several automations.
- A supervisor will ask what the officer had in front of them at the moment they decided, so the file has to be reconstructable exactly as it stood.
How it runs on UiPath Maestro
The process is defined in BPMN and Maestro runs it across agents, robots and people, holding its state for as long as the work takes — including while it waits on an approver.
Step by step
- 01
Application receivedSystem
An account-opening application arrives from a branch, an online form, or a relationship manager, with whatever documents the applicant supplied.
- 02
Read the identity documentsAgent
Identity documents, proof of address and formation papers are classified and extracted, each field carrying a confidence score, with validity and expiry checked against the requirements for that customer type.
- 03
Assemble the evidence fileAgent
Ownership and control are resolved to named individuals, the screening the policy requires is run, and a risk rating is proposed against the institution's own rating rules — every finding cited to the source it came from.
- 04
Clears without an officer?Maestro
The orchestrator routes on the completeness of the file, the confidence behind each field, the screening result, the proposed rating, and the reservation criteria the compliance function maintains as a decision table.
- 05
Compliance officer decidesPerson
The named officer receives the assembled file — documents as submitted, the ownership chain, each screening hit with the evidence for and against it, and the proposed rating with the rule behind it — and records the decision.
- 06
Open the organization recordRobot
An approved customer is created in the core system and the evidence file is filed against the record, under credentials scoped to customer creation only.
- 07
Onboarded and recordedSystem
The relationship is live, and the evidence, the rating, the officer and their reason are written to the audit record.
What each agent is allowed to decide
An agent is only useful in a governed process if its authority is written down. Each one below has a defined input, a decision it may make on its own, and the condition that obliges it to hand over.
Identity Agent
Turns the submitted documents into a structured, checkable identity record.
Reads
- The submitted identity, address and formation documents
- The document requirements for that customer type and product
- Reference data the extracted details have to agree with
Decides on its own
Must escalate when
Entity Structure Agent
Works out who actually owns and controls the applicant.
Reads
- Formation, shareholding and directorship documents
- Registry extracts for each jurisdiction in the chain
- The institution's beneficial-ownership policy, indexed for retrieval
- Group structures already held against related customers
Decides on its own
Must escalate when
Screening and Rating Agent
Runs the required screening and proposes a rating the officer can accept or change.
Reads
- Resolved names, dates of birth and jurisdictions from the file
- Screening results from the lists the policy obliges you to check
- The institution's risk-rating rules, indexed for retrieval
Decides on its own
Must escalate when
What the robots do
Deterministic steps stay with robots — the same action every time, including in systems that never exposed a usable API.
Registry lookup robot
Retrieves registry extracts and filings for the jurisdictions on the application and captures each response as it was returned.
Runs in
Customer record robot
Creates the approved customer and files the evidence pack against the record.
Runs in
Clears without an officer?
Every required document present and above its confidence threshold, the ownership chain resolved to named persons, no screening hit outstanding, and the proposed rating inside the narrow band the institution's policy states may proceed unattended.
- Passes
- Released to customer creation under the policy's own straight-through band, with the assembled file kept intact.
- Does not pass
- Routed to the named compliance officer and held open until they decide.
Modeled as a decision table, so the threshold can be changed by the people who own the policy without redeploying an automation.
The human step
Who
What they see
What they decide
People are in this process because judgment or authority belongs to them — not as a fallback for a step that failed.
What this design deliberately does not do
An automation is only trustworthy if its limits are written down as plainly as its capabilities.
- It does not approve or decline a customer. Where the policy reserves that to a named officer, the process assembles the file and stops until the officer decides.
- It does not clear a screening hit on judgment. It rules out only a clear mismatch on identifiers; a name that still plausibly matches goes to the officer with both records side by side.
- It does not decide which cases are reserved. The reservation criteria are a decision table the compliance function owns, and an agent that cannot place a case sends it to the officer.
- It does not stand in for periodic review. This design covers the file at account opening; a later change in circumstances is a separate process against the same customer.
Failure has a defined path
Systems go down, confidence drops, approvers go on leave. Each of these is a modeled branch rather than a stuck instance.
- A registry or screening provider is unavailable, rate-limited, or returns an error.
- The instance stays open at that step and the robot retries on the schedule Orchestrator holds. The file is never advanced to the gate as though the check had run — a check that did not complete is recorded as not completed. If the outage runs past the window the policy sets, the case is raised as an operational exception rather than left waiting.
- A field falls below its confidence threshold, or an ownership layer cannot be resolved to a named person.
- The gate treats the file as incomplete regardless of what the rest of the evidence says. The case goes to the officer with the specific gap named, the sources that were reached, and no rating presented as final — the agent does not compute a rating on evidence it knows is missing.
- The named officer does not act on the task.
- The task stays open and the instance holds its state. After the interval the policy sets, it is reassigned to the delegate named in the delegation of authority, and the reassignment is written into the file. Nothing is approved by default, and the application is not expired quietly.
- A document is found after the decision to have been superseded or withdrawn.
- The closed instance is not edited. A new instance is raised against the same customer carrying a reference to the original, so the earlier file stays exactly as the officer saw it and the two decisions can be read in sequence.
Data, rollout, and what to watch
Data it touches
- The file holds identity documents and personal identifiers. The design keeps documents and extracted fields in the institution's own store and residency, with the process carrying references rather than second copies.
- Agents see only the fields their step needs. The screening agent works from names, dates of birth and jurisdictions; it does not receive account numbers, balances, or the document images themselves.
- Retention follows the institution's own schedule for onboarding records, and the evidence file is retained as a unit — a document cannot be removed while the decision that relied on it is still held.
- Screening hits describe third parties as well as the applicant. Their detail stays inside the task and the audit record, and is not carried into downstream systems that have no basis to hold it.
How it goes live
- 01
Shadow
The process runs beside the existing onboarding queue on live applications. Agents assemble the file and propose a rating; the officer works the way they work today and never sees the proposal. Where the gate and the officer disagree, the disagreement is what sets the confidence thresholds and the first draft of the reservation table. Nothing the process produces reaches an applicant or a system of record. The phase ends when the assembled file is the one officers would rather work from than the current one.
- 02
Supervised
The officer decides every case, and decides it from the assembled file, which now becomes the record. The straight-through band stays closed — the gate routes everything to a person. The gate into the next phase is the compliance function writing down, and owning as a decision table, exactly which cases it is prepared not to see.
- 03
Unattended with exceptions
Only the band named in that table opens; everything else continues to the officer as before. Straight-through cases are sampled back into review, and anything pulled back changes the decision table rather than the process, so the boundary moves without a redeploy.
Signals worth watching
- The share of applications that reach the officer, split by what held them at the gate — a missing or expired document, an ownership layer that stopped short of a named person, an unresolved screening hit, a rating outside the straight-through band — and whether that mix is shifting.
- How often the officer changes the proposed rating, and whether the changes cluster on one customer type, product or jurisdiction.
- How long tasks sit before they are decided, read by customer type and risk band, and how often a case reaches the delegate named in the delegation of authority before the named officer has opened it.
- How often a hit the agent ruled out on identifiers is later reopened, which is what tells you the matching has gone too loose.
Named without target values. What good looks like depends on your volumes and your risk appetite, and is set with you rather than asserted here.
The UiPath components this design uses
UiPath Maestro
Runs the BPMN process and holds its state for as long as the work takes, including while it waits on a person or a system that is down.
UiPath Agent Builder
Where each agent is defined — its instructions, its tools, its inputs and outputs, and the escalation that sends work to a person.
UiPath Document Understanding
Classification and field extraction, returning a confidence score per field that the policy gate can route on.
Context Grounding
A retrieval index over your own policies and reference data, so an agent cites the rule it applied instead of recalling it.
UiPath Action Center
Where a human step actually lands. The approver gets a task with the agent's reasoning and sources attached, and the process resumes on their decision.
UiPath Orchestrator
Schedules the robots, holds queues and retries, and issues the least-privilege credentials each automation runs under.
UiPath Integration Service
Connectors to the systems of record, so the process talks to them through a maintained integration rather than a bespoke script.
Systems it touches
- Core banking or customer master
- Screening and watchlist services
- Company registry and filing sources
- Document store and case management
What the run leaves behind
- Every document as submitted, and the values extracted from it with their confidence
- The ownership chain as resolved, and the registry extract behind each layer
- Each screening hit, the identifiers compared, and whether it was ruled in or out
- The proposed rating, the version of the rule that produced it, and whether the officer kept it
- The officer's decision, their reason, their name, and the moment it was recorded
Other representative workflows
Talk to us about a process like this.
The most useful first conversation is about a real process — where it stalls, who approves what, and which systems it touches.