KYC & KYB digital onboarding
Identity checks, screening and monitoring wired into one auditable case record
We build the onboarding path a customer walks through and the machinery behind it. Document and biometric checks, KYB work on company registries and beneficial owners, sanctions and PEP screening, then AML transaction monitoring that keeps feeding the same case file your compliance team already works in.
Where it fits
The problem
Verification flows assembled from a vendor's default screens lose applicants at the selfie step, and nobody can say which step lost them. Fuzzy name matching floods the queue with hits on common surnames, analysts clear those by hand, and the reason a filing decision went one way sits in someone's inbox.
What we build
We build the orchestration layer that calls identity, registry and screening providers, holds risk scoring rules per customer segment and writes one case record. Monitoring rules run on a transaction stream instead of an overnight batch, and SAR and STR drafts assemble from evidence the case already holds.
How we engage
Senior engineers who have shipped regulated onboarding, working in your cloud account and your repositories. Customer documents, screening hits and case notes stay inside your infrastructure under your retention rules. We leave runbooks, tests and a trained team, and after that the system is yours to run.
What we build
The pieces we usually build on a KYC and KYB programme.
Identity verification flow
The flow runs on your own screens with document capture, liveness and a fallback path for the applicant whose passport photo will not read. Every step emits telemetry, so a product owner can see where applicants abandon instead of guessing from one conversion number at the end.
KYB and ownership checks
We pull company data from registries and commercial providers, resolve the ownership chain up to beneficial owners and flag the gaps a human has to confirm. Teams doing this in email and PDFs spend days on one corporate customer and cannot show later how the ownership picture was reached.
Sanctions and PEP screening
Screening runs against sanctions, PEP and adverse media lists with matching that handles transliteration, aliases and name order, plus thresholds your team tunes per list and per segment. Out of the box fuzzy matching buries a queue in hits on common surnames, so genuine matches wait behind noise.
Transaction monitoring rules
Monitoring rules run on a transaction stream with typologies for structuring, rapid movement and counterparty risk, and each rule ships only after a replay against historical data. Overnight batch monitoring means an account can move money all day before an alert exists, and tuning stays guesswork.
SAR and STR filing
A case assembles evidence as analysts work, so a filing draft already carries the transactions, the screening hits, the identity record and the narrative in one pack. Reconstructing a filing decision months later from scattered notes is where examinations get uncomfortable and where deadlines get missed.
Audit trail and reporting
Every check, provider response, override and case note is written to an append only trail with the rule version and the operator behind it. When an examiner asks how a customer was risk rated two years ago, the record answers, and reporting extracts run without a manual data pull.
One case record for onboarding, screening and monitoring
A worked example that follows one applicant through verification, a screening hit and the analyst decision that closed it.
How we work
Discover
Systems, constraints, and the regulation you operate under get mapped before implementation starts, so the design accounts for what already runs and for what examiners will ask about.
Architect
A design that fits your stack. Integration-first, self-hostable, and built to change as rules, regulation, and volume do.
Build
Senior engineers ship in tight increments, each tested and reviewed as it goes, so the system is reviewable at every step instead of only at the end.
Harden
Security, compliance, and load-testing run inside the build, so controls, audit trails, and peak-volume behavior are proven before launch.
Run
The handover includes clean, documented systems, with the option to keep the same engineers operating them once they are live.
Why Oxagile
Engineers who know the regimes
Our engineers have built against KYC and KYB requirements, sanctions and PEP screening obligations and AML monitoring programmes. We are a software vendor and hold no licence of our own, so your compliance function owns the policy while we build the mechanism that carries it out and records it.
Evidence an examiner can inspect
Screening hits, provider payloads, risk scores, four eyes approvals and filing decisions all land in one trail keyed to the customer. Compliance teams who keep this in shared drives spend an examination rebuilding history, and the gaps they find are usually in the cases that mattered most.
Fewer applicants lost mid check
Checks are ordered by risk, so a low risk applicant answers less and a flagged one answers more, with a manual review lane behind it. Instrumentation on each step shows which document type, which country and which device drives abandonment, which turns a drop off argument into a measurement.
Questions
Do we have to drop our current screening or identity vendor?
No. We build an orchestration layer with an adapter per provider, so screening, document checks and registry lookups sit behind one interface. That lets you run a new provider in parallel against the same traffic and compare hit quality before you switch anything. It also turns a contract change into a config change rather than a rebuild.
How do you keep customer documents and personal data contained?
Documents and biometric artefacts stay in storage inside your account with encryption keys you hold, and retention clocks run per jurisdiction so files expire on schedule. Analysts see redacted views by default and full records only with a logged reason. Provider calls carry the minimum field set the check requires.
Can our compliance team change thresholds and rules without a release?
Yes. Screening thresholds, risk scoring weights and monitoring rules live in versioned config with an approval step, so one officer proposes and another approves. Each change replays against historical alerts first, so your team sees the queue volume it would create before it goes live. Every version stays in the audit trail.
How do you handle SAR and STR filing?
The case record collects transactions, screening hits and identity evidence as analysts work, then assembles a filing pack in the format your jurisdiction expects, with deadline clocks and a four eyes sign off. Your nominated officer makes the decision. We build the pipeline that carries it, holds the evidence together and records who did what.
Part of Fraud & Identity
Let genuine users through and hold fraud risk down, without turning onboarding into a wall.
Onboarding that converts,
controls that hold.
Where does risk cost you today: false declines, slow KYC, missed fraud? Tell us and we'll tune the system around it.