Where screening belongs in your own lifecycle
The integration question that matters is not which endpoint to call. It is when, and what your system does with the answer. Get the placement wrong and a technically perfect integration still produces files that cannot be defended.
Screening sits after identification and before the risk rating. That order is not a preference:
- Screen after you have verified identity. Screening an unverified identity returns a clean result against a name you have not established belongs to the customer. The result looks the same as a real one and proves nothing.
- Screen before you rate risk. The rating has to take account of what screening found, or it is a rating of a customer you have not finished looking at.
- Screen again over time, not only at onboarding. Lists change; customers do not resubmit. An onboarding-only integration is a point-in-time check presented as ongoing assurance.
Synchronous or batch
Both have a correct use, and the mistake is choosing one for the whole system.
| Call at the moment | Batch | |
|---|---|---|
| Use for | Onboarding, a payment about to be released, any decision a person is waiting on | Re-screening the existing book, list-change sweeps, remediation |
| Volume | One subject | The whole portfolio |
| Failure mode to design for | Timeout while a customer waits | Partial completion nobody notices |
| What your system needs | A defined behaviour when the call does not return | A completion check, not just a job that ran |
The batch failure mode is the one that gets missed. A nightly re-screen that silently processes 80% of the book leaves the other 20% unscreened and the dashboard green.
Handling a match in your own system
A match is not a decision, and an integration that treats it as one will either block good customers or wave through bad ones.
- Never auto-reject on a name match alone. Name similarity without secondary identifiers is the single largest source of false positives, and the cost of an automatic rejection lands on a real customer.
- Route matches to a person, with the comparison data attached. The reviewer needs the identifiers on both sides, not a boolean.
- Give your reviewers a third option. Match, not a match, and cannot determine. Systems offering only the first two push every uncertain case into "not a match", which is how uncertainty disappears from the record.
- Make the decision, not the alert, the thing you store. Alerts are transient; decisions are the evidence.
What to log, and why
The audit question is never "did you screen". It is "show me what you screened, against what, and what you did about it". Your system needs to be able to answer that without querying ours.
Record, on your side:
- The subject as submitted, including how the name was spelt
- Which data sources were in scope for that check
- The timestamp, and the version or date of the data if available
- The result, including no-match results — an absence of alerts is only evidence if it was recorded
- For any match: the identifiers compared, the decision, the decision-maker, and the reasoning
- Any document relied on, stored rather than linked
The commonest gap here is the fifth one. Teams log alerts and not clean results, then cannot show that a customer was screened at all on a given date.
Questions to settle before you build
These are the ones that are expensive to change later, and they are questions for your own architects as much as for us:
- Where does the screening record live? If it lives only in the screening platform, your customer file is incomplete; if only in your system, you lose the source data. Most teams need both, with a stable identifier joining them.
- What is your behaviour on failure? A screening call that errors must not silently onboard a customer. Decide whether you queue, block or degrade, and make it explicit.
- What is your re-screening trigger list? Time-based alone is not enough. Change of beneficial owner, new jurisdiction, unusual activity and adverse media all belong on it.
- Where is the data processed and stored? A jurisdictional question with contractual consequences; settle it before integration rather than during procurement.
- Who can change a threshold? Matching thresholds are a control. If a developer can change one without a compliance approval, the control is not governed.
What this page does not yet cover
Being direct about it: the endpoint-level reference is not published here — base URLs, authentication, request and response shapes, error codes and rate limits. Those come from the product team, and we would rather say so than publish an approximation a developer would build against.
If you are scoping an integration now, talk to us and we will get you the current reference along with a sandbox.
For the operational side of what the integration has to support, the checklists cover programme design, customer risk assessment, enhanced due diligence and alert review.