Home/Offers/Banking, Payments & Credit/AML Screening API

Banking, Payments & Credit

AML Screening API

Screening is easy to do badly. A name matcher with a loose threshold will find every sanctioned party and bury your compliance team in false positives until it finds nothing at all.

Banks
Payment service providers
Fintechs
Crypto exchanges
Insurers

Discuss This Build See What It Returns

What your customers would see

example interface

MockupIllustrative mockup of the interface we would build. Figures shown are examples, not results from a live deployment.

The problem this solves

The structural problem with sanctions screening is that the lists are short and the alerts are many. A bank screening a million customers against a few tens of thousands of designated parties will generate alerts overwhelmingly dominated by coincidental name similarity — and the response to that flood is almost always to tighten thresholds, which is the one adjustment that creates genuine risk of a missed match.

Getting out of that trade-off requires using more than the name. A designation record carries dates of birth, places of birth, nationalities, known aliases, addresses and identifier numbers. A customer record carries some subset of the same. Scoring the agreement across all available fields, rather than matching on a transliterated string, is what separates a tolerable alert volume from an intolerable one. Transliteration itself is a substantial piece of work: a name written in Arabic or Cyrillic script has many defensible Latin renderings and sanctions lists contain several of them inconsistently.

Adverse media is a different kind of problem, and worth being blunt about. It is unstructured, of wildly varying reliability, and prone to the two failures that matter most — attributing an article about one person to a different person with the same name, and treating a years-old allegation that was later dismissed as a current risk indicator. Any adverse media capability that does not handle entity disambiguation and allegation lifecycle properly produces alerts that waste reviewer time and occasionally defame customers.

Who buys this

Banks, Payment service providers, Fintechs, Crypto exchanges, Insurers

Category: Banking, Payments & Credit

What the API returns

What comes back

Screening results against sanctions, PEP and watchlist sources with per-field match detail
Match score decomposed by field, so a reviewer sees exactly why the record matched
Transliteration-aware name matching across scripts and naming conventions
PEP classification by role, seniority, jurisdiction and relationship type
Adverse media hits with source reliability grading, allegation category and current status
Entity relationship graph linking customers to associates, officers and ownership chains
Ongoing monitoring with alerts when a list changes or a customer record changes
Complete audit record per screening, reproducible with the list versions used at the time

Endpoints

Method	Path	Returns
POST	/v1/screen	Screen one party against the configured source set
POST	/v1/screen/batch	Batch screening or periodic re-screening of a customer base
GET	/v1/alerts/{id}	Full alert detail with per-field match evidence
POST	/v1/alerts/{id}/disposition	Record a reviewer decision and the reasoning
GET	/v1/parties/{id}/relationships	Relationship graph for a screened party
POST	/v1/monitoring	Register parties for ongoing screening with change alerts

Request and response

illustrative

Request

{
  "party": {
    "type": "individual",
    "full_name": "Mohammed Al-Rashid",
    "date_of_birth": "1974-03-18",
    "nationalities": ["AE"],
    "country_of_residence": "GB",
    "identifiers": [{ "type": "passport", "country": "AE", "value_hash": "sha256:9f21\u2026" }]
  },
  "sources": ["sanctions", "pep", "adverse_media"],
  "sensitivity": "balanced",
  "reference": "onboarding_88201"
}

Response

{
  "screening_id": "scr_2026102111120408",
  "result": "potential_match",
  "alerts": [
    {
      "alert_id": "alr_44120",
      "source": "sanctions",
      "list": "consolidated_designations",
      "list_version": "2026-10-20",
      "designated_name": "Muhammad al-Rashid",
      "match_score": 0.64,
      "field_agreement": {
        "name": 0.91, "date_of_birth": "no_data_on_list",
        "nationality": 1.00, "identifier": "no_match"
      },
      "assessment": "Name and nationality agree; list record has no date of birth, so the match cannot be excluded on that basis",
      "recommended_disposition": "manual_review"
    },
    {
      "alert_id": "alr_44121",
      "source": "adverse_media",
      "match_score": 0.38,
      "article_count": 2,
      "allegation_category": "financial_misconduct",
      "status": "proceedings_discontinued_2021",
      "source_reliability": "medium",
      "entity_confidence": 0.41,
      "assessment": "Low confidence that the article subject is this party; proceedings discontinued",
      "recommended_disposition": "discount_with_note"
    }
  ],
  "clear_sources": ["internal_watchlist"],
  "audit_reference": "scr_2026102111120408"
}

Where the data comes from

Official sanctions and designation lists	Published consolidated lists from the authorities relevant to your jurisdictions, which are the only authoritative source for designations
PEP data	Either licensed from a commercial provider or assembled from official appointment records; licence terms almost always prohibit redistribution and sometimes caching
Licensed news and media archives	Adverse media requires licensed content with permitted machine access — scraping news sites for this purpose breaches terms of use at most publishers
Company registry and ownership data	For resolving corporate parties and building the relationship graph that makes indirect exposure visible
Your own internal watchlists	Previously declined or exited relationships, which are frequently your most relevant screening source and entirely yours to use
Reviewer disposition history	Your own true and false positive decisions, which are what tuning should be calibrated against rather than a vendor default

On data licensing. Being allowed to read a dataset does not automatically mean you may redistribute it, resell it through an API, or train a model on it. Before any build starts we check the licence, terms and derived-data rules of every source, and we design around the ones that do not permit your intended use. Where a commercial licence is required, that cost is identified during discovery rather than discovered later.

The intelligence layer

The difference between a demo and a service is mostly in this section. These are the parts that keep the answer trustworthy once real traffic is hitting it.

Multi-field probabilistic matching rather than name-only comparison, with per-field agreement weights tuned on your own disposition history
Transliteration handling across scripts with multiple romanisation standards, plus name-order, patronymic and compound-surname conventions by region
Explicit handling of missing fields: a list record with no date of birth cannot be excluded on date of birth, and the alert says so rather than silently scoring it down
Fuzzy matching bounded by phonetic and edit-distance families chosen per script, because a single similarity metric behaves badly across writing systems
Entity disambiguation on adverse media using corroborating attributes, with an entity confidence reported separately from the allegation severity
Allegation lifecycle tracking so dismissed, acquitted or discontinued matters are presented with their current status rather than as live risk
Threshold tuning measured as a recall/precision curve on your own labelled alerts, so a sensitivity change is a quantified trade rather than a guess
List version pinning on every screening, so a decision made in March can be reproduced against the lists as they stood in March

What it changes for the business

Lower false positive volume

Multi-field matching reduces the alert flood that drives threshold loosening, which is the actual source of screening failure.

Explainable alerts

Per-field match evidence lets a reviewer dispose of an alert in seconds instead of reconstructing the comparison by hand.

Audit reproducibility

List versions pinned per screening mean a historical decision can be reproduced exactly, which is the first thing an examiner asks for.

Relationship visibility

Indirect exposure through officers and ownership surfaces at onboarding rather than during a later investigation.

How it fits into your product

How it embeds

Synchronous screening at onboarding and before payment release, with batch endpoints for periodic re-screening of the whole base
Alerts routed into your existing case management system with the full field-level evidence attached
Disposition feedback so reviewer decisions continuously tune matching rather than sitting in a case log
Webhooks when a list update or a customer record change creates a new match on a monitored party
Configurable sensitivity per product, jurisdiction and risk appetite, set by your compliance function and not by us
Deployment inside your infrastructure, which licence terms for PEP and media data frequently require in any case

Included in every build

Authentication, scoped API keys and per-customer rate limiting
Input validation with predictable, documented error responses
Versioned endpoints so your integration never breaks without notice
Request and response logging for audit and dispute resolution
Latency, error-rate and usage monitoring with alerting
OpenAPI specification, sandbox environment and client examples
Backups, failover design and a documented recovery procedure
An agreed support arrangement once the service is live

How we would build it

about 20 weeks

Discovery and feasibility

Weeks 1–3

This one depends heavily on data access, so we start by proving the sources exist, can be licensed for your use, and actually carry the signal the model needs. If they do not, you find out here.

Architecture and baseline model

Weeks 4–6

A written architecture and a baseline model measured against a holdout period, so you know what accuracy you are buying before the full build starts.

Production build

Weeks 7–16

Data pipelines, model training and serving, historical archive, validation harness, API, security, monitoring and documentation.

Validation and integration

Weeks 17–20

Backtesting against held-out history, accuracy reporting your team can audit, integration support and an agreed retraining cadence.

Commercial models

There is no fixed price list, because the cost is driven by data complexity, integration count, model requirements, request volume and the support level you need. Scope is agreed in writing before development starts.

Fixed-scope prototype

A defined slice of the service, built and priced as one piece of work. The usual first step when the business case needs proving internally.

Fixed-price build

An agreed scope against a written architecture, delivered for an agreed price. Best when the requirements are already clear.

Build then retainer

We build the service, then operate and improve it under a monthly agreement covering monitoring, updates and model maintenance.

White-label product

The service runs under your brand, your domain and your pricing, with MLPivot invisible to your customers.

Questions buyers ask

Can this replace our commercial screening vendor?

Sometimes, and sometimes it should not. Sanctions screening against official published lists is entirely buildable and often better than what you have, because you control the matching logic and the tuning. PEP and adverse media depend on licensed data you would still be paying for. More importantly, some regulators and correspondent banks expect a named commercial provider, and that expectation is a business fact rather than a technical one. It needs settling before the build.

Will this reduce our false positives?

Multi-field matching reduces them substantially compared with name-only screening, which is what most alert floods actually come from. But there is a floor: a customer who genuinely shares a name and nationality with a designated party, where the list record carries no distinguishing attributes, is an alert that cannot be resolved automatically and should not be. Some irreducible manual review is the correct outcome, not a failure.

How do you handle adverse media reliability?

By reporting entity confidence and allegation status separately from severity, and by grading source reliability. A tabloid allegation from 2016 against someone who may or may not be your customer is not the same input as a current regulatory enforcement notice, and collapsing them into one score is how screening systems generate alerts that cannot be acted on. We would also recommend scoping adverse media narrowly at first — defined allegation categories, graded sources — rather than screening against everything.

Can we cache the PEP and media data?

Usually not freely. Commercial PEP datasets are typically licensed for screening use with explicit restrictions on storage and redistribution, and news archives are more restrictive still. Official sanctions lists are published and reusable. We check each licence during discovery and design the architecture around the restrictions, which sometimes means a source is queried live and only the alert evidence is retained.

What happens when a list changes overnight?

Monitored parties are re-screened against the delta as soon as the updated list is published, and new matches raise alerts immediately. The practical caveat is publication latency: we poll official sources directly rather than waiting on an aggregator, but we cannot be faster than the authority that publishes the designation.

All Banking, Payments & Credit offers →

Want this built for your platform?

Tell us what your product does today and what you want another system to be able to ask it. We will come back with an approach, a scope and a price.

Discuss This Build Browse All Offers