What a fintech software development company actually builds when you say KYC/AML platform

*Can we onboard customers in under two minutes, screen every one of them against sanctions and PEP lists, and still keep the compliance team small enough that the unit economics work?*

Those three constraints fight each other. Loosen screening and the regulator arrives. Tighten it and the alert volume buries a five-person compliance team. Speed up onboarding and you push decisions to automation that has to be defensible in an audit two years later.

The engineering answer is not a better model. It is a system where every automated decision leaves a reconstructable trail, and where alert volume is a tuned parameter rather than an accident.

Vendors fail differently, and they fail often. Document verification, liveness, sanctions data and company registries come from different suppliers with different SLAs, different regional coverage and different definitions of "match". Any one of them being slow or down must not stop onboarding.

False positives are the whole operating cost. Fuzzy name matching against sanctions and PEP lists produces alerts at rates that are routinely in the high tens per hundred hits before tuning. Every alert is human minutes. A platform that screens correctly but generates unreviewable volume has failed commercially even though it passed compliance.

Nothing can be deleted, and nothing can move. Regulators expect the exact inputs, list version, rule version and reviewer rationale behind a decision made years earlier. Several jurisdictions also require that personal data stays inside a border. Those two requirements shape the storage design before a line of application code exists.

The core idea: one orchestration service owns the decision, vendors sit behind adapters, and every state change is written to an append-only decision log.

flowchart TD
    A[Customer onboarding<br/>web / mobile SDK] --> B[Onboarding API<br/>region-pinned]
    B --> C{Orchestration service<br/>decision owner}

    C --> D[Vendor adapter layer]
    D --> D1[Document + liveness<br/>primary vendor]
    D --> D2[Document + liveness<br/>fallback vendor]
    D --> D3[Company registry<br/>KYB source]
    D1 -.circuit breaker.-> D2

    C --> E[Screening engine]
    E --> E1[(Sanctions lists<br/>versioned snapshots)]
    E --> E2[(PEP + adverse media)]
    E --> E3[Fuzzy match<br/>+ alias / transliteration]

    C --> F[Risk scoring service<br/>rules + model score]
    F --> G{Decision}
    G -->|Clear| H[Approved<br/>auto-onboard]
    G -->|Alert| I[Case queue<br/>tiered by risk band]
    G -->|Block| J[Rejected + SAR candidate]

    I --> K[Reviewer workspace<br/>disposition + rationale]
    K --> L[(Append-only decision log)]
    H --> L
    J --> L

    L --> M[Ongoing monitoring<br/>rescreen on list delta]
    M --> E
    L --> N[Regulator reporting<br/>+ audit export]

    subgraph Residency["Per-region data plane"]
        B
        L
    end

Three properties of this diagram do the work. The orchestration service is the only component allowed to declare a decision, so there is one place to audit. Vendor adapters normalise every supplier to one internal verdict shape, so swapping a vendor is a config change and not a rewrite. The decision log is append-only and holds the list version and rule version in force at decision time, so a case reopened in 2029 replays exactly as it ran.

Ongoing monitoring is the loop most builds forget. Screening at onboarding is a snapshot. Lists change weekly; the platform rescreens the existing book against each list delta rather than re-running the whole population.

1. Blueprint: modelled the alert budget before the architecture. We started from the compliance team's capacity — reviewers × minutes per case × working days — and derived the maximum sustainable alert rate. Every screening threshold was then tuned to fit that budget. This inverts the usual order and it is the single most consequential decision in the build.

2. Prototype: built the screening engine against real list data first. Not the UI, not onboarding. Fuzzy matching with transliteration, alias handling and date-of-birth corroboration, tested against a labelled set before anything else existed.

3. Forge: wrapped every vendor in an adapter with a circuit breaker and a fallback. Timeouts, retries with jitter, and a defined degraded mode where onboarding continues into manual review rather than failing.

4. Forge: made the reviewer workspace a first-class product. Side-by-side evidence, the exact match reason, one-keystroke disposition, mandatory rationale. Review time per case is the metric that decides whether the platform is affordable.

5. Harden: built residency in as deployment topology, not as a filter. Region-pinned data planes with a shared control plane holding no personal data.

6. Harden: shipped the audit export and reporting path before go-live, because a reporting layer retrofitted onto a live book is a data-migration project.

The eval set. A labelled corpus assembled from three sources: historical cases with known dispositions from the operator's existing process, synthetic near-miss identities generated to stress alias and transliteration handling, and the public sanctions lists themselves used to construct true positives. Typical size for a first build is several thousand labelled records, deliberately over-weighted toward the hard middle — names that are close but not matches.

The metric that mattered. Not accuracy. Recall on true sanctions matches is treated as a hard floor that cannot be traded, and the tuning objective is the false-positive rate at that fixed recall. Teams that optimise a blended score end up trading away exactly the detections they cannot afford to lose.

Typical movement in these builds is a reduction of roughly 40–70% in alert volume at unchanged true-positive recall, achieved through corroborating identifiers, list-scope discipline and per-band thresholds rather than by lowering match sensitivity. Range, not a promise: it depends entirely on how untuned the starting configuration was.

Latency. Screening is a synchronous step in onboarding, so it gets percentile targets, not averages. We hold p50 in the low hundreds of milliseconds and p99 under one to two seconds for the screening call, with the vendor calls run concurrently and budgeted separately. Onboarding end to end typically lands in the one-to-three-minute range including document capture, which is human time, not system time.

Failure modes, and what happens when the system is wrong. A missed true match is the unrecoverable failure, so the system fails toward review: any vendor timeout, any ambiguous match, any degraded-mode onboarding routes to a human rather than auto-clearing. A false block is recoverable but damaging, so blocks require a rules-plus-score agreement and are always re-reviewable with the original evidence intact. Every automated decision is reversible in the record without editing history — reversals are new entries, not overwrites.

The tradeoff we took. We chose synchronous screening inside the onboarding flow and paid for it in latency engineering. Asynchronous screening after provisional approval is faster to build and gives a nicer conversion funnel, but it means a customer can transact before screening completes. In a regulated book that is a position nobody wants to defend.

The alternative we rejected. A single full-stack identity vendor covering verification, screening and monitoring. It is dramatically less work up front. We rejected it because it puts commercial and regulatory dependency in one place, hides the match logic behind an API you cannot tune, and makes regional coverage gaps unfixable. The adapter layer costs weeks; vendor lock-in costs years.

The thing that broke. Name normalisation. Transliteration of non-Latin scripts, honorifics, patronymics and ordering conventions produced both silent misses and noisy duplicates in early testing. It took a dedicated normalisation stage with per-locale rules and a golden test set to stabilise, and it was the largest single unplanned cost in the build.

Bring compliance reviewers into the Blueprint, not the UAT. We have run this both ways. When the people who will live in the queue shape the disposition workflow in week two, review time per case lands lower and stays lower. When they see it in week eighteen, the workspace gets rebuilt.

Version the rules from commit one. In one build we introduced rule versioning after go-live. Backfilling which rule version applied to already-decided cases was avoidable pain. It is now in the schema from the first migration.

Do not build adverse-media screening in the first release. It carries the worst precision of any screening source and it consumes reviewer attention that the core sanctions and PEP flow needs. Ship it in the second phase, once the alert budget has headroom.

Reference builds of this shape stay in software development support after go-live for threshold retuning as the book grows, list-source expansion into new markets, and reviewer-throughput monitoring. Screening tuning is not a project that finishes; the population changes and the thresholds follow it.