Technical acceptance requirements for sanctions screening software in 2026
This checklist is for compliance, risk, security, and engineering teams testing a screening workflow in their own environment. It is not a universal regulatory checklist, procurement scorecard, or promise about a provider.
For commercial comparison, RFP evidence, and rollout ownership, use the guide to choosing sanctions screening software. For detailed calibration and representative matching tests, use the false-positive reduction guide.
1. Set the acceptance scope before the demo
Record the parties, workflows, systems, jurisdictions, and sources in scope. Distinguish onboarding, batch imports, API requests, ongoing monitoring, and payment or counterparty processes. A browser demonstration does not prove that production submits the same fields or retains the same evidence. For each path, name the owner, system of record, expected input, acceptance result, and reviewer handoff.
2. Verify API field contracts and identity linkage
Request the API contract and test it against your payloads. Confirm required and optional fields, normalisation, rejection, truncation, and preservation of supplied values. Test names, aliases, dates of birth, addresses, identifiers, entity names, country values, and relevant scripts.
Acceptance evidence should include:
- Request and response schemas, formats, limits, and validation errors.
- Stable request, result, source-record, and case identifiers that link to internal records.
- Behaviour for missing, contradictory, duplicate, and unsupported values.
- Whether work is synchronous, queued, or partial, and how final status is retrieved.
- Versioning and notice for field, endpoint, and response-semantic changes.
Do not assume that a score, status, or identifier has the meaning your workflow needs. Capture the documented meaning and test the consuming system.
| Requirement to test | Practical test | Evidence to retain |
|---|---|---|
| Input integrity | Send a representative party record and compare submitted and accepted field values | Sanitised request, response, validation result, and field-mapping record |
| Identity linkage | Follow one request through the screening result and internal case | Correlation identifiers and the retrieval path in both systems |
| Contract change | Test the documented handling of an added, absent, or invalid field | Contract version, test result, owner approval, and change notice |
The expected evidence is not a particular field name or endpoint. It is a reproducible demonstration of the behaviour that your integration relies on.
3. Test failures, timeouts, retries, and idempotency
Run controlled tests for network interruption, client timeout, service error, malformed input, rate limits, duplicate submission, delayed completion, and webhook redelivery. Ask for error codes, retry guidance, timeout limits, retry-after behaviour, idempotency-key semantics, and the state model for asynchronous work.
Confirm what happens when the client receives no response but the request was accepted. Test whether retry returns the original result, creates a new run, or needs reconciliation. Document who investigates an unknown state, where authoritative status is retrieved, when work may be retried, and how duplicate results are identified.
| Scenario | Test question | Expected evidence to assess |
|---|---|---|
| Client timeout after submission | Can the team determine whether the request was accepted? | Contract guidance, status lookup result, and reconciliation record |
| Partial batch completion | Are completed items distinguishable from items needing recovery? | Item-level outcomes, error detail, and rerun procedure |
| Duplicate request | Does the documented retry approach avoid unintended duplicated work? | Idempotency or correlation evidence and observed outcome |
| Delayed webhook or redelivery | Can the consumer safely process a late or repeated notification? | Delivery event record, consumer log, and final internal state |
Use the provider's documented retry timing and status semantics as the test baseline. If those details cannot be produced or do not fit the workflow, record an open gap rather than inventing a recovery rule.
4. Require source, version, and change traceability
For a potential match, verify that a reviewer can retrieve or export the source record, source identifier, list version or publication date, ingestion time, aliases, and relevant identifiers. Test a source update or controlled equivalent: establish what changed, when it reached the relevant workflow, and whether the event remains linked to the prior result and case. Define the source and update evidence your organisation requires instead of accepting broad coverage claims.
5. Make audit reconstruction a practical test
Ask an independent reviewer to reconstruct a completed test case without help from a presenter. They should establish the submitted party data and sender, screening execution, configuration or policy reference, source state, visible result context, reviewer actions, notes, escalation, decision, timestamps, and any later change that reopened work.
Save the export, API response, screenshots, and access path used. Where evidence is split across systems, document correlation identifiers and retention ownership. See the alert documentation guide for per-alert investigation evidence.
Example acceptance record
The following is illustrative. It is not a prescribed status model, API response, or product claim.
| Field | Illustrative entry |
|---|---|
| Acceptance item | Recover a submitted request with an unknown client outcome |
| Test reference | INT-REC-04 |
| Expected outcome | The team can identify the final provider-side outcome and prevent duplicate internal processing |
| Observed outcome | Pending review after a status lookup returned insufficient correlation evidence |
| Evidence owner | Integration lead, with compliance review |
| Evidence location | Approved test repository and case record reference |
| Disposition | Open gap, follow-up required before production approval |
Pass means the agreed test completed with sufficient, retrievable evidence. Fail means observed behaviour conflicts with the agreed criterion. An open gap means the result, documentation, access, or ownership is incomplete; it should not be silently counted as a pass. Assign one owner for obtaining provider evidence and one internal owner for accepting or rejecting it.
6. Validate access, security, and data operations
Test the access model, not only a questionnaire. Confirm analyst, approver, administrator, integration, and auditor roles can perform only intended actions. Agree the evidence required for data in transit and at rest, environment separation, logs, retention, deletion, residency, subprocessors, incident notification, backup, and continuity. Policy- or jurisdiction-specific requirements are your criteria, not universal product capabilities.
7. Test operational resilience under realistic load
Define a bounded test volume for batch size, concurrency, peak periods, and downstream dependencies. Observe queueing, partial failure, monitoring signals, support escalation, and recovery rather than only a favourable response time. Record conditions, results, unresolved failure modes, owners, and rollback or manual-continuity procedures. Confirm incident, maintenance, and breaking-change communication and the information available for reconciliation after recovery.
8. Record evidence and open gaps
For every criterion retain the requirement, test data, environment, expected and actual results, evidence location, reviewer, date, and disposition. Treat an undocumented answer, unrepeatable demonstration, or result outside the agreed workflow as an open gap until resolved. The evidence pack tests the specified data, configuration, source state, and integration at that time; repeat relevant tests after material changes.
Keep the acceptance record separate from the commercial decision. The buyer guide can help structure that decision; this record should make technical assumptions and unresolved recovery paths visible to the people who own them.
Ready to evaluate the operational fit of a screening workflow? Explore Checklynx sanctions screening and validate the relevant contract, workflow, and evidence path with your team.
Continue reading AI AML screening