What connects today, what is a seam, and what is not built

A versioned REST endpoint for single canonical events, authenticated by a tenant-scoped service-account credential with ingest permissions only. Idempotent on the source system and external reference, and it returns accepted, duplicate or quarantined per event.

Bounded file upload with row-level quarantine and resumable processing. Six required columns — account reference, external reference, booking timestamp, direction, amount in minor units and currency — plus seven optional ones that make rules worth writing, including channel, counterparty and corridor country.

A core banking export is mapped onto the canonical columns by a JSON document naming the system and a stable format identifier, written by an implementation engineer during deployment. Every Nigerian bank's export is a different set of column names over the same few facts, and hand-writing an adapter per bank makes the tenth one as expensive as the first.

No vendor-specific adapter and no pre-built mapping ships for any core banking product. The adapter interface and the mapping engine exist; the mapping for your export is written during implementation and proven against your own files.

The adapter interface for a scheduled export pull is defined, with its timeout, retry and quarantine semantics. No adapter is registered, so the supported pattern today is the institution's own scheduler pushing to the ingest API or delivering the canonical file.

Not offered and not on a near roadmap. Reading a core banking database directly couples an AML system to another product's schema and makes every core upgrade an AML incident.

No switch adapter is built and no credentials are held. The interface, its failure policy, its timeout and its provenance rules are implemented and tested; connecting one is an adapter project with a contract, a data-use agreement and acceptance tests behind it.

Defined as a half-open window request returning the same canonical file format the ingest parser reads — half-open because a closed window re-fetches the boundary transaction on the next run, and a duplicated transaction inflates every aggregate a structuring rule computes.

Two instructions only, both carrying an idempotency key: stop a payment pending a compliance decision, and reverse that hold. There is no instruction that initiates a transfer, because an adapter that could would be a far larger blast radius than anything an AML system needs.

Not built. Inline interdiction changes the availability requirements of the whole deployment — the platform becomes part of the payment path — and that is a deliberate architectural decision, not a configuration flag.

The request shape, the outcome vocabulary and the provenance model are implemented; no NIBSS client, no credentials and no commercial agreement exist in this build. A verification request with no adapter returns not-configured, and an unverified identifier is never rendered as verified.

As above. Both the provider selection and the harder operational question — what the institution does when the authority is unreachable at onboarding — are open decisions rather than engineering work.

Company registration verification, and with it any automatic confirmation of a declared beneficial-ownership register against the CAC record. Ownership verification today is a recorded human act against a named evidence reference.

Checks that a BVN or NIN is shaped like one and applies a single documented canned-response convention, so a demonstration or a QA pass can exercise the onboarding flow end to end. It registers as a fixture, its result is stored as a mock assurance, it cannot satisfy the tier approval gate, and both it and the registry refuse it when the environment is production.

A SCUML registration number is captured and encrypted exactly as supplied and recorded as supplied-unverified. No live SCUML registry check is connected.

Entries with aliases matched independently, entity kinds, reason codes, corroborating nationality and expiry dates; soft removal with a required reason; and export under permission.

CSV import that applies the rows it can and quarantines the rows it cannot, keeping the line number, the error and the raw line for inspection. Re-using an external identifier updates the existing entry rather than creating a second one.

Publishing reads the complete live master and writes an immutable version. It is idempotent on content, and every hit produced afterwards pins the version it matched against.

A list can be bound to an adapter identifier, a list kind, a source and a refresh interval, with an enable flag that defaults to off. The refresh runs on schedule and records its result honestly — which today means recording that no provider is registered under that identifier, on every run.

The adapter shape — identifier, licence declaration, fetch and normalise — is defined, and a feed's licence is checked before a fetch is attempted. No feed adapter ships. Publication is deliberately not part of the provider interface, because publishing is where the audit entry is written and the version every hit pins is fixed.

Same interface, same absence, plus a licensing question the institution and the vendor have to answer together before an adapter can be written: whether the feed may be redistributed to the deployment shape you intend to run.

An XSD or schema version is registered with its format and named regulator provenance, and field mappings are validated for target path, requiredness and expression correctness before they can be proposed.

The stored document is the bytes as they would be transmitted, downloadable and printable with its digest, so what is filed is what was approved.

The reference the external channel actually returned, the time it was filed, and the payload and schema digests that bind the delivery to that exact document — plus acknowledgement or rejection attached afterwards to the same immutable history.

The schemas shipped with the build are placeholders and are marked as such. A report generated against one cannot be submitted — refused by the request handler, by the reporting service and by a database constraint. The authoritative artifacts are obtained and accepted by the institution's MLRO.

No filing transport exists. If one is ever built, the contract is already written: it must not mark a report submitted until the channel provides delivery evidence bound to the exact payload digest.

An optional relay delivers scheduled internal aggregate packs with an artifact digest and a recorded run ledger. Where no relay is configured the ledger records the refusal rather than claiming a delivery. These packs cannot create, submit or acknowledge any regulatory filing.

Any standards-compliant issuer reachable over HTTPS, with an audience and a confidential client. Authentication belongs to your identity provider; authorisation belongs to the platform. Issuer, audience, claims, actor status, tenant and permission are validated before a handler runs.

Managed or self-operated, with separate logins for separate jobs — a runtime role that is not the table owner and holds no bypass on row-level security, a platform role for estate metadata, and a migration owner scoped to the migration job.

Both adapters are write-once: the filesystem commits with an atomic hard link, S3 uses a conditional put, and neither has a delete operation. The store receives ciphertext and an opaque key only. A store that does not honour the conditional put is not acceptable as an evidence store, and there is a documented test to prove it before go-live.

Root keys, database credentials and client secrets are injected from your secret store rather than baked into a values file or an image. A rehearsed key-escrow procedure is a requirement, not a recommendation: a database backup without the root key is unreadable.

All three are genuinely optional. Redis is a shared configuration cache, recommended above one API replica; SMTP delivers scheduled board packs; an OTLP collector receives traces. Absence of any of them is a tested, supported configuration rather than a degraded one.