Compliance that scales: KYC routing and the auto-screening pipeline

For a regulated money business, compliance is not a feature you bolt on — it is a gate every transaction passes through. The challenge is doing that without turning the gate into a bottleneck. MEXAR’s answer is to make both KYC and transaction screening configurable pipelines: ordered, pluggable steps that run automatically and stop the moment something fails.

KYC, routed by document type

Identity verification in MEXAR runs as a session with a clear lifecycle:

DRAFT → PENDING → SCREENING → APPROVED / REJECTED

While a session is in DRAFT, the user can add or remove identities, contacts, addresses, and files. On submission it moves to PENDING, enters SCREENING, and ends APPROVED or REJECTED — each terminal state stamped with its timestamp and, on rejection, a failure reason.

What makes it scale is routing by identity type. Different documents are best verified by different vendors, so MEXAR sends each to the right one automatically:

• Passport → RegTank (kyc_platform = 'regtank')
• National ID → Glair (kyc_platform = 'glair')

Underneath, a pluggable driver decides how screening runs. With the msa driver, a bridge builds a structured payload and calls the screening service over HTTP (POST /api/v1/screen), moving the session to PENDING on success and recording an error on failure. With the local driver, the same work is dispatched as an in-process job instead. The calling code does not change; only the driver does — so a deployment can run managed or self-contained without touching the workflow.

Results come back via callback, which updates both the screening queue and the session — kyc_verified_at, kyc_rejected_at, or an error state — so the outcome is always recorded, never inferred.

Transaction screening: an ordered reviewer pipeline

Every transaction runs through an auto-screening pipeline assembled from reviewers declared in configuration. They execute in order, and stop on the first failure — so a transaction that trips an early rule never wastes work on later ones, and the result names exactly which reviewer blocked it and why.

'rules' => [
    'transaction' => [
        BlacklistEntityReviewer::class,
        DepartmentLimitationReviewer::class,
        DescriptionReviewer::class,
        EntityLimitationReviewer::class,
        ComplianceRuleReviewer::class,
    ],
],

Because the list is configuration, the pipeline is genuinely pluggable: reorder it, drop a reviewer for a market that does not need it, or assemble a custom subset for a specific flow. Each reviewer is a small, independently testable unit with one job — checking a blacklist, enforcing a department limit, validating a description, applying an entity limit, or evaluating a compliance rule.

Fast blacklist matching

Blacklist checks have to be quick even when the list is large, so MEXAR picks data structures to match the job. Entity screening tests the name against the blacklist via a Bloom filter — a space-efficient structure that rules out the vast majority of non-matches instantly — alongside checks on address and identifiers. Free-text keyword screening uses Aho-Corasick, which scans for many blacklisted terms in a single pass rather than searching for each one separately.

The point is throughput: screening sits on the hot path of every transaction, so the matching has to be cheap enough to never become the reason a transaction is slow.

Why pipelines, not hardcoded checks

It would be simpler to bury a few if statements in the transaction code. MEXAR deliberately does not, because compliance requirements change — by corridor, by regulator, by month — and a hardcoded check is a redeploy every time. Expressing KYC routing and screening as configurable, pluggable pipelines means an operator can adapt to a new obligation by changing configuration and adding a reviewer, not by rewriting the core.

That is the same design principle that runs through the platform: provider modules swap by contract, side-effects run as decoupled listeners, and compliance runs as an ordered pipeline you can reshape. The gate stays strict — and stays out of the way.