Automating customer onboarding: verification, risk and the file

Onboarding a customer combines three things: gathering information, verifying it, and deciding whether to accept the risk. The first two automate well and consume most of the time; the third is a decision with regulatory consequences, and automating it completely is neither the objective nor usually permissible.

Below: why onboarding gets abandoned halfway, what automates in each stretch, what each country requires, how the risk decision is designed, and what to measure.

Onboarding has a feature that sets it apart from other administrative processes: it happens while the customer can still walk away. Every additional step, every document that has to be sent again and every day of waiting translates directly into abandoned applications.

And at the same time it carries requirements that cannot be skipped. That tension — do it fast and do it properly — is exactly the ground where automation contributes, provided it is clear which part can resolve itself and which cannot.

Why it gets abandoned halfway

The causes repeat. The first is asking up front for everything that might be needed later rather than what is required to begin. A long form deters before it contributes.

The second is asking twice for the same data, because the uploaded document is not read and the information is requested again in a field. It is the most visible sign of a process that does not integrate its own pieces.

The third is silence. A file under review with no indication of how much remains generates queries to the service channel and, after a few days, abandonment. The automation that retains most is not the one that decides: it is the one that informs.

What automates in each stretch

Collection improves when the form adapts: asking only what the customer type and product require, and pre-filling everything derivable from an uploaded document.

Document verification resolves well with automatic reading: extracting the data from the identity document and contrasting it with what was declared catches most inconsistencies without intervention. Checking validity and internal coherence is rules work.

Consulting external sources — restrictive lists, confirming a company exists, tax standing — is pure integration and should resolve in seconds.

Assembling the file, which is what will stand as evidence in a review, requires no judgement and is nonetheless usually done by hand. It is among the stretches that return most time and receive least attention.

What each country requires

In Colombia, supervised entities operate under a risk-management system for money laundering and terrorism financing, with explicit obligations on customer knowledge, segmentation and reporting. In Mexico, the anti-money-laundering framework defines vulnerable activities, identification thresholds and notices to the authority.

They agree in substance — know the customer, score their risk, keep evidence, report — and differ in thresholds, deadlines and formats. The practical consequence is the same as in other regulated processes in the region: an implementation designed for one country arrives incomplete at the other, and the design has to contemplate both from the start if the operation is regional.

To this is added personal data protection, which here is particularly sensitive: the file contains identity documents and frequently financial information. Habeas Data in Colombia and the federal data protection law in Mexico condition who may access it and how long it is kept.

The risk decision, and why it is not fully automated

Scoring a customer combines objective signals — economic activity, location, product requested, results of the checks — with judgement. The objective part calculates itself and should, because a consistent calculation beats one that depends on who is reviewing.

What should not run unsupervised is rejection. A negative decision affects a person or a company and, in several contexts, can be appealed. A model that rejects without anybody able to explain why is an operational problem before a technical one: somebody will have to answer that question.

The design that holds automates the low-risk path, routes the rest to review with all the evidence gathered, and records which signals led to each outcome. That traceability is what a review asks for, and reconstructing it afterwards is far more expensive than generating it as you go.

The corporate case, which is the hard one

Onboarding a person is relatively bounded: a document, some checks, a decision. Onboarding a company introduces a different problem — establishing who actually controls it, and that chain can run several levels deep.

Both frameworks require identifying the beneficial owner, and it is the point where most files end up incomplete. The information usually exists in public registries, but scattered and in formats that do not lend themselves to automated lookup, so the stretch ends up resolved by hand with criteria that vary by whoever does it.

What can be automated is the scaffolding: requesting the corporate documentation at the right moment, extracting the declared structure, contrasting it with what the available sources return, and flagging the discrepancies. The decision on a complex structure stays human, and arrives with the preparatory work done rather than starting from nothing.

The file as the product of the process

It is worth inverting the usual framing. The objective of onboarding is not to approve a customer: it is to produce a defensible file that also happens to let you operate with that customer.

Seen that way, several decisions change. Evidence is stored at the moment it is obtained rather than reconstructed at the end. Every external check is recorded with its date and result, because "we checked" without a date is not evidence. And periodic refresh stops being an annual project and becomes a continuous flow.

That last part is what usually fails: organisations with impeccable onboarding and thousands of files that have not been refreshed in years. The refresh is straightforward to automate and almost never is, because it belongs to nobody: the onboarding team considers the customer handed over, and the servicing team never owned the file.

What to measure

Four figures describe the whole process. Time to first transaction, the business metric. Abandonment rate by stage, which shows exactly where people are lost. Share resolved without intervention. And share of files passing a quality review, the risk metric.

The last two are deliberately in tension, and that tension is healthy: raising automation at the cost of file quality moves the problem to a future audit, where it costs considerably more.

The starting point comes from mapping the real process and its per-stage times, waiting included. It is common to find that verification takes minutes and the file waits days for an internal signature. A process automation assessment produces that map with feasibility and a recommended order, and where the process touches sensitive personal data the design decision is taken together with cybersecurity rather than after it.

Frequently asked questions

Which part of onboarding should be automated first?

Document verification and external source checks, because they are deterministic and fast. And assembling the file, which requires no judgement and is usually done by hand despite consuming considerable time.

Can the decision to accept or reject a customer be automated?

The objective scoring yes, and it should be: a consistent calculation beats one that depends on who reviews. Rejection without supervision is different, because it affects a person or company and can be appealed; somebody must be able to explain why.

Does the same design work in Colombia and Mexico?

Not without adapting it. Both frameworks require knowing the customer, scoring risk, keeping evidence and reporting, but they differ in thresholds, deadlines and formats. A design built for one arrives incomplete at the other.

Why are applications abandoned halfway?

Asking up front for everything that might be needed later, asking twice for the same data, and silence: a file under review with no indication of how much remains generates queries and then abandonment.

What has to be recorded?

Every external check with its date and result, and the signals that led to each decision. "We checked" without a date is not evidence, and reconstructing traceability after a review costs far more than generating it as you go.

What is the hardest part of corporate onboarding?

Identifying the beneficial owner. The information exists in public registries but scattered and in formats that resist automated lookup, so it ends up resolved by hand with criteria that vary by who does it.