Baobyte AML Suite
Book a demo

Fintechs and PSPs

Machine-speed intake, human-speed decisions, one evidence trail

Your transactions arrive by API, your onboarding is measured in seconds, and your alert volume grows with your success. What does not scale by adding servers is the part where a person decides something and has to defend it two years later. This page is about connecting those two halves without either one degrading the other.

  • CBN payment-system licences
  • API-first ingest
  • Instant payments
  • High-volume digital onboarding

Obligations

What a licensed payment business has to demonstrate

Licence categories change what you may do. They do not change whether you owe a programme.

CBNA licensed payment business owes a full AML/CFT programme
Payment-system licence categories differ in what the operator may do — switching and processing, payment solution services, mobile money, payment service banks — and not in whether an AML/CFT programme is required. Board-approved policy, a designated compliance and reporting officer, risk assessment, CDD, monitoring, records, training and independent testing apply across the categories.
CBNTiered identity requirements, and what they permit
Nigeria operates a tiered customer-identification framework in which lighter verification carries correspondingly limited account functionality. The compliance consequence is that the tier is a control, not a marketing feature: if the tier a customer sits in is not enforced against their actual activity, the tiering has not been applied.
NFIUReporting duties do not move with the sponsor relationship
Where a fintech operates under, or alongside, a licensed bank, who holds the reporting obligation for which activity has to be documented and agreed rather than assumed. Both parties monitoring the same flow and each assuming the other files is a common and expensive failure mode.
FATF-alignedOriginator and beneficiary information on transfers
Payment messages are expected to carry the information needed to identify the parties, and a receiving institution needs a defined policy for handling transfers where it is missing. For an API-first business this is a data-contract problem as much as a policy one.
SanctionsScreening at machine speed, decisions at human speed
Designated-party obligations apply without delay, which for an instant-payments business means screening has to run in the flow. What follows a hit — clear, escalate, freeze — is a human decision with an evidence trail, and treating it as an automated one is where institutions get into trouble.
NDPAIdentity data at volume attracts proportionate obligations
Selfies, identity documents and device signals collected during onboarding are personal data with lawful-basis, retention, minimisation and subject-rights consequences. Verification providers are processors and need contracts, data-use terms and a documented failure policy.
Sector-specificVirtual assets, where you are licensed for them
Operators licensed for virtual-asset activity attract an additional set of obligations distinct from payment-system licensing. If any part of your business touches it, treat the scope question as a legal one to settle before configuration rather than after.

Operational reality

Where high-volume payment businesses actually get hurt

  • Intake is a firehose and the compliance team is notVolume growth is linear in transactions and superlinear in alerts if the rules are not tuned. Every fintech reaches the point where the queue grows faster than hiring can absorb, and the answer is subject-level consolidation and prioritisation rather than another analyst.
  • Instant payments are irrevocable, so detection timing is the controlBy the time an overnight batch job flags a structured set of transfers, the money has left. What is achievable is real-time screening, near-real-time detection and a fast, evidenced escalation path — not a promise that the system will stop the transaction on its own.
  • The same person opens forty accountsCheap digital onboarding makes account-farming, mule networks and synthetic identities the dominant typology. Detecting it needs identity and device signal joined to activity across accounts, which means the customer record and the transaction record have to live in the same system.
  • A verification provider times out and the record says 'verified'The most damaging integration bug in this segment is silent substitution: an unavailable provider outcome written into the record as a clean one. It is invisible until an examination samples the file. The platform refuses to map an unknown or unavailable provider outcome to a verified value — it stays explicitly pending.
  • Engineering owns the integration, compliance owns the consequenceA schema change ships on Thursday, the monitoring layer starts receiving a null where an amount used to be, and nobody finds out until the month-end numbers look wrong. Ingest that quarantines and reports invalid records — rather than dropping them — is what keeps that from being a silent gap in coverage.
  • Auditors ask what your service account can readMachine integration is usually the first thing a security review probes. A service credential that can read customer or case content is a finding; one that is opaque, digest-only, scoped to ingest permissions and revocable is not.

Integration

The intake contract, in full

Written for the engineer on the evaluation call. Every row below is a behaviour the ingest layer guarantees, not a configuration option.

What the ingest layer does with each awkward case
CaseWhat happens upstreamWhat the platform does
Duplicate deliveryRetry the same eventIdempotent — the same source event resolves to the same record rather than double-counting
Malformed recordA field is missing or the wrong typeQuarantined and reported, never silently dropped from the monitored population
Mixed currenciesA batch carries more than one currencyRefused or kept as approved separate totals — never silently aggregated
Provider unavailableAn identity check times outRecorded as explicitly pending or unavailable, never substituted with a clean value
Machine credentialYour ingest service authenticatesOpaque and digest-only, scoped to machine permissions, rotatable and revocable, with no human role
BackfillYou replay six months of historyThe same idempotency and quarantine rules apply, so a backfill cannot quietly rewrite the monitored record

Getting live

Connect, normalise, detect, adjudicate

The order matters. Teams that start with rules before settling the canonical transaction shape spend the first month tuning against data that is still changing underneath them.

  1. Connect

    Issue a scoped service account, point your ingest at the transaction API, and confirm the quarantine and idempotency behaviour against deliberately bad fixtures before real traffic.

  2. Normalise

    Map your event shape onto the canonical transaction model, with currency and amount units explicit. This is where mixed-currency and null-amount problems are found, not in production.

  3. Detect

    Start with a small set of rules you can defend, versioned and approved. Add typologies as you evidence them rather than importing a library you cannot explain.

  4. Adjudicate

    Alerts land in a human queue with the rule trace attached. Analysts investigate in a subject-consistent case; only an authorised reporting officer can file.

Platform

Which capabilities carry this segment

Integrations

Idempotent transaction ingest, currency-safe amounts, quarantine and reporting of invalid records, and machine identities that are separate from human ones.

Learn more

Transaction monitoring

Explainable rules over normalised activity, with velocity and structuring patterns evaluated across accounts belonging to the same subject rather than per account.

Learn more

Screening and watchlists

Screening in the payment flow with retained source, version and match evidence, so a cleared hit at 02:00 is still defensible at an examination.

Learn more

Customer and CDD

Onboarding records that keep provider outcomes honest — an unavailable verification stays pending rather than being written into the file as clean.

Learn more

Investigation and casework

Subject-consistent cases that collapse forty alerts across forty accounts into the one investigation they actually are.

Learn more

Security architecture

Opaque, digest-only service credentials with one-time reveal, rotation and revocation, scoped so a machine identity cannot read customer or case content.

Learn more

Examination readiness

What you can produce about any transaction that ever arrived

  • The ingest record for any transaction: when it arrived, whether it was accepted or quarantined, and under which service account.
  • The rule and rule version that raised an alert, replayable deterministically against the same input.
  • Screening evidence with the list source and version as they stood at the moment of the hit.
  • One case per subject, with every account, alert and screening hit belonging to that subject linked to it.
  • Service-account lifecycle: issue, rotation, revocation, and every permission the credential ever held.
  • The provider outcome for each identity check, including the ones that failed or timed out.

Proof

Fintech and PSP case study

Reserved for an operator that has approved publication.

Placeholder — no fintech or PSP engagement has been approved for publication. Replace with sourced, approved content before this page is made public.

Reserved for an operator that has approved publication

The write-up will cover ingest volumes, how the alert-to-analyst ratio moved, what the integration actually took in engineering time, and what the operator's own security review found.

Challenge
Volume, alert load and where monitoring ran before.
Approach
Integration shape, rule set adopted, and the tuning cycle that followed.
Result
Outcomes with a defined baseline and measurement window.

—

Transactions ingested

Awaiting a figure with an as-at date.

—

Alerts per analyst

Awaiting an agreed definition and a baseline.

—

Integration effort

Awaiting the operator's own engineering record.

Questions

What engineering and compliance ask

Does this block transactions in real time?
Screening and detection run against the flow, and the platform's job is to raise the signal with its evidence attached. Whether a payment is held is a decision your payment stack and your policy own — a compliance platform that quietly becomes a payment authoriser is a platform whose failures become outages.
What can our ingest service account actually see?
Machine permissions only: submit normalised transactions and batches, and receive ingest outcomes. It cannot read customer, case or report content, and it cannot assume a human role. The negative case is covered by the release test suite rather than by documentation alone.
We already have rules in our own stack. Why move them?
You may not need to move all of them. What is hard to build alongside a payment system is the part after detection: versioned rule provenance, deterministic replay, subject-consistent casework, four-eyes closure and filing evidence. That is the part examinations look at, and it is where most in-house monitoring stops.
How does this handle a customer with forty accounts?
By treating the subject rather than the account as the unit of investigation. Alerts across accounts that resolve to the same subject correlate into one case, which is also the only way an analyst can see a mule network as a network rather than as forty separate false positives.

Related reading

Start the conversation

Send us a schema, not a requirements document

The quickest way to establish whether this fits is to map one of your real transaction events onto the canonical model and run it through ingest — including the malformed and duplicate cases. That conversation takes an hour and settles most of the evaluation.

Book a technical demoRead the API reference