Role
AML and KYC
How many times last week did an alert turn out to be false? If it is nearly always, the team's attention is being spent on noise - and attention is the most expensive resource here.
Intro call
Four questions we would start with
How often does an alert turn out to be a false hit?
If it is in more than nine cases out of ten, the first problem is not detection, it is handling.
Who notices first that a client's ownership structure has changed?
If nobody does until the next periodic review, then what you know about the client is a photograph from the day the relationship began.
How quickly do you find out that a client has been added to a sanctions list?
Days or weeks - that is the difference between a response and a regulatory problem.
Whose desk does an alert end up on when it cannot be closed either way?
And whether that decision is recorded anywhere together with its reasoning.
We take over gathering data and handling the noise, you keep the risk assessment
Assembling client data, pre-screening false hits, watching review dates and preparing documentation can be taken off the desk. The client risk assessment and the decision to report stay with a person.
- An alert arrives with its context. - The client data, the history of previous alerts and the reason for the hit in one view, instead of opening four systems.
- False hits are pre-screened, not closed. - A hit that clearly does not match on identity is marked as such, and a person confirms it.
- A change at the client is a signal. - A change of ownership structure, of address, or an entry on a list does not wait for the periodic review.
Scope
What can be taken off AML and KYC
Twenty example tasks. Each one has a human approval point. Below is a selection, and the scope we fit to your client profile.
Verification at onboarding
- Assembling client data from public registers as a starting point
- A summary of the ownership structure for verification (establishing the beneficial owner: the specialist, on the basis of independent sources)
- Checking sanctions lists and politically exposed persons
- Pointing out gaps in the documentation before the relationship goes live
- A proposed client risk level (decision: the specialist)
Transaction monitoring
- Detection rules by client profile
- Comparing transactions against the declared business profile
- A signal when behaviour departs from what is typical for that client
- A summary of related transactions
Handling alerts
- An alert with full context and history
- Pre-marking hits that clearly do not match (confirmation: the specialist)
- An alert queue ordered by risk level
- Recording the decision with its reasoning (decision: the specialist)
Reports and reporting
- Assembling the material for a report
- A draft report (approval: the specialist)
- Watching the deadlines set by the regulations
- A register of reports with restricted access
Periodic reviews
- A review schedule by client risk level
- A signal when client data changes between reviews
- A summary of clients whose documentation is out of date
A day's work
Today
- You assemble client data by going through several registers
- You establish the ownership structure by hand, level by level
- You open an alert with no context and work out yourself what it concerns
- You close false hits one after another, exactly as you did a month ago
- You learn about a change at a client during the periodic review
- You record decisions to close an alert briefly, with no reasoning
With AI assistance
- The data from the registers is assembled, you verify it against independent sources
- The ownership structure is laid out, you verify it
- The alert arrives with context, history and the reason for the hit
- Hits that clearly do not match are marked, you confirm
- A change at a client reports itself between reviews
- The decision has its reasoning recorded and is available during an inspection
- Share of false alerts
the team's attention goes to the cases that need judgement
hits that do not match are pre-marked
- Time to handle an alert
a case closes faster and with better reasoning
the context and the history sit with the alert
- Complete verification
fewer relationships go live with gaps in the documentation
the gaps are pointed out before the start
- Ready for a supervisory inspection
decisions are documented and can be reconstructed
the reasoning is recorded with the decision
We start with context on the alert, because that is where the team's time comes back fastest.
- Step 1
The alert with context and history
Client data, the reason for the hit, previous decisions in one view.
- Step 2
Pre-screening hits that do not match
Marking, not closing. Confirmation always stays with a person.
- Step 3
Assembling data at onboarding
Public registers, ownership structure, sanctions lists.
- Step 4
Reviews and signals about changes
A schedule by risk and signals between reviews. Last, because it needs the client data to be in order.
Common questions
Questions that come up at the first meeting
Does the beneficial ownership register not settle the matter?
No, and this is an important distinction: the regulations expressly forbid relying on the register alone when establishing the beneficial owner. The register is a starting point and a good way to spot discrepancies, but verification requires independent sources and documents on your side. The scope we propose assembles the data - establishing the beneficial owner stays an act of the institution.
What about clients served for years whose documentation is incomplete?
That is the usual debt and it cannot be made up in one step. We start with the highest-risk clients and with those whose data has changed, and only then work downwards. What matters is that the list of gaps exists at all.
Will the AML team be smaller?
The regulator expects alerts to be handled and documented, so the number of people follows from the volume and the regime, not from the tool. Taking over the context and the pre-screening changes what the team's attention goes on: the cases that need judgement instead of the hits that obviously do not match. In this area that is a stronger argument than saving money.
Does this fall under the AI Act?
Transaction monitoring and client verification are not in themselves a high-risk use, but the area sits close to the line: assessing the creditworthiness of individuals is treated as high risk in the regulations. That is why we hold to the rule that the client risk classification and the decision to report belong to a person, while the system supplies the material and records the reasoning.
Still have a question that is not here? Book a call
Next step
How long does it take you to close one obviously false alert?
We will show you what AML handling looks like when the alert arrives with context and the decision is recorded with its reasoning.