Real-Time vs Batch AML Screening: Architecture Trade-offs
Whether a check runs at the moment of an event or on a schedule shapes your customer journey, your failure handling and the evidence you can show later. This guide compares the patterns.
Three patterns and what each leaves behind
Real-time (event-driven)
It fits when:
- The outcome of the check decides whether the customer may continue, for example at account opening or before funds leave.
- The action cannot easily be undone once it completes.
- You can design a sensible behaviour for the case where the screening service does not answer.
Evidence for an auditor: One record per event, tied to the exact request, the answer received and the decision taken at that moment.
Batch (scheduled)
It fits when:
- You are re-checking an existing customer base after the underlying lists have changed.
- Activity can be reviewed after the fact without harm to the customer or to you.
- You prefer one controlled job that is easy to rerun over many small calls.
Evidence for an auditor: One record per run, showing what was in scope, which list versions were used, what was raised and who reviewed it.
Hybrid
It fits when:
- You gate the moments that matter in real time and sweep everything else in a scheduled job.
- You want the sweep to catch customers whose status changed after they were onboarded.
- You can keep one case queue so analysts do not work two disconnected lists.
Evidence for an auditor: Two streams of records that must reconcile: every real-time decision can be traced to a customer the sweep also covers, and a sweep hit can be matched to any earlier real-time decision.
Failure and retry handling
When the screening call fails
Decide in advance whether the flow pauses, queues the action for review or proceeds with a flag. Each choice is a risk decision, so write it down, name the approver and test it.
Retries and duplicates
A retried request must not create a second case or a second decision. Use a stable identifier for each event so that a repeat is recognised and the record shows one outcome.
Late and out-of-order messages
Asynchronous callbacks can arrive after the customer has moved on. Store the time of the request and the time of the answer separately, and define what happens to a result that arrives late.
Partial batch runs
A job that stops halfway must say where it stopped. Record the scope, the position reached and the rerun, so no customer is silently skipped.
Questions to take to the vendor
- How long does a check take in ordinary and in busy conditions, and what is committed in the agreement?
- Does the interface support one identifier per event so that retries are safe?
- Can the same list versions be used for a real-time check and a later sweep, and is the version recorded?
- How are missed callbacks found and replayed?
For the wider vendor conversation, use the vendor evaluation checklist and the FinTech and crypto criteria. The AML software landscape shows where each tool category sits, and the AML audit readiness guide covers how evidence is organised for an examiner.
Product and company names belong to their owners and are used only to identify them.
Frequently Asked Questions
Is real-time screening always the safer choice?
What will an auditor ask about either pattern?
Where does FRAMEWORQ sit in this architecture?
Does this guide give performance targets?
Find the gaps. Close them. Prove it.
Stay audit-ready with FRAMEWORQ, our compliance readiness platform. Free 3-month trial, and a pilot if you want one.