Unknown block type: SchoolHeader
Unknown block type: SchoolNav

KYC & Compliance

Checks, approvals and an audit trail on every action

What actually goes wrong

Seven ways a file becomes a finding

Nobody fails an audit on the policy. They fail on what the policy cannot prove.

Most compliance failures are not decisions that were wrong. They are decisions that were fine and cannot be shown to have been fine — approved by somebody who was online at the time, on a document that arrived by email, against a policy that lived in a Word file and had been superseded twice.

The work below is therefore less about checking and more about recording: who looked, what they saw, what they decided, and when. Get that right and the checking part becomes routine. Get it wrong and no amount of diligence survives the first review that asks for evidence.

  1. 01

    Documents arrived by email and stayed there.

    Clients upload through the portal or the app, straight onto their own record, with the document type declared as it goes. Nothing is forwarded, nothing sits in an operator’s mailbox, and nobody has to work out later which of four attachments was the one that was actually approved.

  2. 02

    Every file was read by a person, including the obvious ones.

    Veriff and Sumsub run the automated checks first — document authenticity, face match, liveness, data extraction — and only the cases that genuinely need judgement reach a queue. The onboarding desk spends its day on the exceptions instead of clearing passports that a machine had already read correctly.

  3. 03

    Screening was done once, at the beginning.

    Sanctions, PEP and adverse media screening runs at onboarding and again on a schedule, because the client who was clean in March is the risk you did not know you had in September. Hits open a case with the match detail attached rather than an alert somebody has to go and interpret.

  4. 04

    Whoever was online approved it.

    Approval rights sit on the operator, not the department, and higher-risk cases route to the people allowed to take them. A four-eyes rule can be required where it matters. The name on a decision is the name of somebody who was entitled to make it, which is the first thing a reviewer checks.

  5. 05

    The risk score lived in a spreadsheet.

    Risk is scored on the record from country, product, document quality, source of funds, screening result and behaviour, and it drives what happens next: the checks required, the approval level needed and how often the client is reviewed again. A score nobody can act on is a number, not a control.

  6. 06

    Onboarding was so thorough that clients gave up.

    Requirements are set per country, per product and per risk band, so a low-risk client is not asked for a bank statement they do not need to provide. The client sees exactly what is outstanding and what has cleared, and the desk sees where applications are stalling rather than only that they did.

  7. 07

    The regulator asked for the trail and it took three weeks.

    Every action is written against the client, the operator and the time — approvals, rejections, overrides, field edits, document views and the logins themselves. The trail cannot be edited from inside the console, and it is exported from the same screen rather than assembled by another team from four sources.

What is in it

Collect, verify, decide, and prove it later

The first three are the work. The fourth is the one that gets audited.

  1. Stage one

    Collect

    What a client is asked for depends on where they are, what they are opening and what they scored. Requirements are configured rather than coded, so a new jurisdiction is a rule change, and the client is never asked twice for something already on the record and still in date.

    • Upload from the portal and the mobile app
    • Requirements per country and product
    • Document types and accepted formats
    • Proof of address and source of funds
    • Corporate and joint account structures
    • Expiry dates with advance warnings
    • Progress visible to the client
  2. Stage two

    Verify

    The automated providers go first and the queue only sees what they could not settle. Screening runs at onboarding and on a schedule afterwards, and a hit becomes a case with the match detail attached rather than a notification that somebody has to chase down themselves.

    • Veriff and Sumsub integration
    • Document authenticity and data extraction
    • Face match and liveness
    • Sanctions and PEP screening
    • Adverse media checks
    • Ongoing rescreening on a schedule
    • Manual review queue for exceptions
  3. Stage three

    Decide

    Risk scoring drives the route a case takes, and the route decides who is allowed to close it. Rejections carry a reason from a list your compliance team controls, so a year of rejections is something you can read patterns out of rather than a column of free text.

    • Risk scoring on the record
    • Approval rights per operator
    • Four-eyes on higher-risk cases
    • Enhanced due diligence workflow
    • Structured rejection reasons
    • Periodic review scheduling by risk band
    • Account restrictions and freezes
  4. Stage four

    Prove

    Not a log you go and find, but the record a review asks for, ready before it is asked for. Every action against every client, immutable from inside the console, exportable by the people entitled to export it and logged when they do.

    • Full action trail per client
    • Operator, timestamp and previous value
    • Document view and download logging
    • Immutable from inside the console
    • Read-only compliance access across the book
    • Export with its own audit entry
    • Retention rules per jurisdiction

Who signs in

One queue, six sets of rights

Who may look, who may decide and who may only read is the whole control.

  • Onboarding. The exception queue and little else: documents in, automated checks run, and the handful of cases that genuinely need a person looking at them rather than a rubber stamp.
  • Compliance officers. Screening hits, enhanced due diligence cases and the periodic review calendar, with the authority to restrict an account and the obligation to say why on the record.
  • The MLRO. Read across the entire book, the escalation path into their queue, and the reporting that has to leave the building with a name attached to it.
  • Support. Whether a client is verified and what is outstanding — enough to answer the question on the phone, without sight of the documents themselves.
  • Sales. The onboarding status of their own book, so they know whether to chase a document or a deposit, and nothing about anybody else’s clients at all.
  • Auditors and management. Read everything, change nothing, and pull the trail out without asking another team to run an export first.

Nobody fails a review for the decision they made. They fail for not being able to show they made it.

Get Your Demo Read the FAQ

Questions about the module

Before your next review

What a compliance team usually wants to establish before it signs off on a new system.

  • Veriff and Sumsub are integrated directly, wired to your own accounts with your own rules rather than ours, so the checks that run are the ones your compliance team configured with the provider. Results come back onto the client record with the evidence attached — the extracted data, the match outcome, the provider’s own reference — which is what makes the decision reproducible later. If you already run a different provider, it connects through the open API on the same shape.

  • They have to, and they do. What a client is asked for is set per jurisdiction, per product and per risk band, so a low-risk retail client in one market is not asked for the source-of-funds evidence a higher-risk corporate account in another one needs. It is configuration rather than development, which matters the first time a regulator changes something with sixty days’ notice: the rule is edited, the outstanding applications pick up the new requirement, and nobody waits on a release.

  • Every one. Each action is written against the client it touched, the operator who did it and the time it happened — approvals, rejections, overrides, restrictions, field edits, document views and downloads, and the logins themselves. Where a value changed, the previous value is kept beside the new one. The trail cannot be edited from inside the console by any role, including the ones that can change everything else, and exporting it creates an audit entry of its own.

  • On a schedule you set, and by risk band. A client who cleared sanctions and PEP screening at onboarding is not permanently clear — circumstances change, and lists change more often than clients do. Rescreening runs in the background, and a hit opens a case with the match detail attached rather than firing an alert that somebody has to interpret from scratch. Periodic reviews work the same way: the risk score sets the interval, and the calendar is the module’s rather than a diary reminder somebody keeps.

  • Yes, and you choose where. Four-eyes can be required on higher risk bands, on enhanced due diligence cases, on account restrictions or on overrides of an automated result, while routine approvals stay with one operator so the queue still moves. Rights sit on the operator rather than the department, which means a stand-in covering a colleague on leave does not inherit an approval level they were never granted — the single most common way a four-eyes policy quietly stops being one.

  • Wherever your compliance position requires. Brokers whose data has to stay on infrastructure they control deploy on their own server; desks that would rather not run servers let us host it. Deployment, upgrades and monitoring are handled either way, and retention rules are set per jurisdiction so documents are kept for as long as the rules say and no longer. The choice is about where the data sits, not about which version of the product you get.