When onboarding is fully automated: what to do first
An automated onboarding flow does not remove the compliance file — it moves the file into logs, model versions and audit trails. The first task is to freeze what the system decided, capture who signed off on it, and confirm the file is complete before any transaction proceeds.
The legal basis
Where the onboarding tool sits inside a crypto-asset service provider's client acquisition flow, the relevant framework is Regulation (EU) 2023/1114 (MiCA). It sets the authorisation and conduct obligations a provider carries when taking on a new client, regardless of which tool performs the underlying check. The obligation attaches to the provider, not to the software the provider chooses to run.
Where the same onboarding also triggers a transfer of funds or crypto-assets, Regulation (EU) 2023/1113 (TFR) governs the originator and beneficiary information that has to travel with that transfer. An automated onboarding decision does not exempt the transfer from this requirement; it only determines how quickly the required information reaches the counterpart institution. Both regulations came into force on 30 December 2024, and neither treats automated decision-making as a separate category of client relationship.
Automation does not create a new category of client relationship under either regulation. The threshold questions — is this client the person they claim to be, is the source of funds legitimate, does the transfer trigger the same information requirements — remain identical whether a human or a model made the initial call. What differs is only the format of the record a provider must be able to produce when asked to show how it reached that call.
What changes in practice
A human reviewer who onboards a client leaves a trail that is easy to question later: handwritten notes, a signature, a dated approval. An automated system leaves a different kind of trail — a model version number, an input dataset, a threshold that fired or failed to fire. That trail is equally auditable, but only if someone exports it before the next software update quietly changes the underlying logic. Retention obligations do not pause because the underlying decision was automated: the same period applies to a machine-generated approval as to a signed paper file, and a vendor's default log rotation is rarely built with that period in mind. The practical risk is not that automated onboarding is unlawful in itself. The risk is that the file supporting a given decision becomes unreconstructable within weeks, once the model has moved on and nobody kept a snapshot.
The onboarding tool itself is usually licensed, not built in-house. Where that licence involves royalty payments to a vendor abroad, a separate cross-border tax question opens up alongside the compliance question. When withholding tax hits the royalty flow sets out what changes at the payment stage.
If the vendor's underlying technology is itself under a live patent challenge, the tool's future availability can no longer be assumed, and a contingency plan is worth having before it is needed. When the other side files revocation first covers what that challenge means for a licensee who relies on the contested technology.
Contract terms for the tool matter as much as its accuracy score. Where a vendor refuses the liability terms your compliance file requires, the procurement itself stalls before the tool ever reaches production. When the customer refuses a limitation of liability covers that negotiation on its own terms, separately from the AML file.
None of these three questions is an AML question in itself. They matter here only because a compliance file that depends on a single vendor's tool is only as reliable as that vendor's contract, technology and continuity — and an onboarding decision inherits that dependency whether the file mentions it or not.
Vendor due diligence before go-live
Before an automated onboarding tool ever touches a live client, it is worth confirming in writing: what data the model was trained on, how false negatives are measured, and how often the vendor revises the scoring logic without notifying customers. A vendor that cannot answer these three questions in writing is not necessarily unusable, but the compliance file then has to compensate with a heavier manual review layer, which defeats much of the point of automating the check in the first place. Where the vendor operates from outside the EU, confirm separately how it handles data residency for the underlying client records, since that question sits outside the scope of either regulation cited above and is usually addressed in the service contract instead.
What to do, in order
- Export the decision log for the client in question: model version, score, timestamp, and the specific rule that fired or did not fire.
- Name the accountable role that signed off the onboarding, even where the sign-off itself was generated automatically.
- Check the file against your internal completeness checklist before any transaction is allowed to run on the account.
- Where an element is missing, stop the onboarding and escalate immediately — do not let the transaction outrun the file.
- Record the vendor name and version of the onboarding tool inside the client file itself, not only in separate IT documentation.
- Confirm the retention period for the decision log matches your standard client-file retention, not a shorter default set by the vendor.
- Route the escalation to the named compliance officer, not to the engineering team responsible for maintaining the tool.
- Note the date the export itself was taken, separately from the date of the original onboarding decision, so the file shows when the snapshot was captured.
An incomplete file behaves the same whether the gap was left by a person or by software, and the clock on closing it starts the same way in either case. When the file is incomplete on AML: what to sets out what a supervisor expects once that gap is identified.
Who decides, and on what evidence
Your compliance officer decides whether the automated outcome stands, on the evidence the system itself produced at the time of the decision. A supervisory authority reviews that same decision later, on the same file — it does not re-run the automated check or rebuild the model from scratch. What persuades a supervisor is a legible export: a fixed snapshot of the inputs, the threshold, and the output at the moment the client was onboarded, rather than a live dashboard that keeps recalculating in the background.
None of this requires the supervisor to have any special expertise in the vendor's model. The file is expected to explain itself in plain terms — what data went in, what came out, and why that output was accepted — regardless of how sophisticated the underlying scoring method is. Where a supervisor disagrees with how a flagged case was handled, the usual next step is a written request for the underlying file, followed by a deadline to respond that runs from the date the request is received, not from the date of the original onboarding decision. Building the export habit before a review is announced saves considerably more time than reconstructing it afterwards under a deadline set by someone else.
| Signal in the file | What it usually means | Your next step |
|---|---|---|
| Automated approval with no override field logged | Escalation path was never wired into the tool | Add a manual override field before the next onboarding batch |
| Score threshold changed mid-quarter, no version note kept | Past decisions can no longer be explained on today's logic | Freeze and archive the prior model version with its own audit trail |
| Vendor cannot produce the data behind a given score | The file rests on reasoning you cannot independently defend | Request the vendor's documentation in writing, or add a fallback manual check |
If your situation differs
If the automated tool has already onboarded clients before this question was raised, the file cannot be rebuilt with perfect accuracy after the fact — the priority shifts from perfection to documenting the gap honestly, rather than smoothing it over in the record.
Who decides, and on what evidence
You remain the decision-maker on every automated onboarding, even where a tool produces the score. A supervisor assessing the file later looks at whether a human could override the system, whether the logic behind a given decision can be reconstructed, and whether the model version in force at the time was recorded. The vendor's documentation supports that account; it does not replace it.
What this page does not settle
This page does not tell you whether a specific automated decision was correct, which turns on the data behind it, and it does not set national supervisory deadlines, which are stated in the notice you receive. It does not replace a file-by-file review by someone who has seen the actual onboarding records.
FAQ
What is the first step when onboarding is fully automated?
Confirm that a human override exists and is logged, before the next onboarding batch runs. An approval no one can override or explain is the gap a supervisor tests first.
Which deadline is already running?
The internal one your compliance function must set the moment the gap is identified — the clock on documenting and closing it. There is no statutory clock here, but silence after the question is raised reads as a decision.
Who decides, and on what evidence?
Your compliance officer decides, on whether the automated logic can be reconstructed and defended, not the vendor whose tool produced the score.
Verified
Checked against the record-keeping and governance duties that apply to obliged entities under the applicable EU framework. The review date for this page is shown in its metadata.