Keeping KYC simple for clients and compliance

KYC has two customers: the regulator, who wants every client identified and screened, and the trader, who wants to deposit today. Brokerages that treat them as opposed end up with either a leaky funnel or a compliance backlog. The ones that get both right follow a few principles, and they are the principles behind RedCherry's onboarding and KYC module.

Automate the checks, keep the decisions

Document authenticity, face matching, address validation and sanctions screening are machine work; providers such as Sumsub, Shufti Pro and Didit do them in minutes with a risk score attached. The decision on a flagged case, and the policy behind the rules, stays with your compliance team. Automation removes the queue of routine approvals so the team can spend its time on the cases that need judgement.

Ask for documents once, in the right order

A client asked for the same document twice, or for a proof of address before they have confirmed their email, gives up. Sequence the steps: email, phone, identity, address, each with a clear status in the portal and an automatic email when it changes. Country-based onboarding keeps the list of documents to what that jurisdiction actually requires.

Use levels instead of a single gate

Verification levels let a client do something at each stage. Confirmed email and phone: explore the portal and open a demo. Identity verified: deposit. Address verified: withdraw. Permissions per level mean compliance is enforced where it matters, the withdrawal, without blocking the first deposit behind the slowest check.

Make status visible

Most KYC tickets are 'what is happening with my documents'. Showing the current level, what is pending and what the next step is in the client area removes those tickets, and lets the support desk answer the rest from the same record compliance works on.

Keep the evidence

An audit asks who approved what, when and on what basis. Every approval, rejection and document request should be logged with the staff member and time, and the provider's result stored on the profile. In RedCherry that trail is written automatically, alongside the roles and permissions that decide who can make the decision in the first place.

A level structure that fits most brokerages

• Level 0, registered: email and phone confirmed; can open a demo account and explore the portal
• Level 1, identity verified: document and face check passed; can deposit up to a limit and open a live account
• Level 2, address verified: proof of address accepted; deposit limits lifted, withdrawals allowed
• Level 3, enhanced: source of funds or extra checks for high-value clients, applied by risk score rather than to everyone

The exact levels follow your licence, but the pattern is the same: each level unlocks something the client wants, and the heaviest checks apply only where risk justifies them.

Handling flagged cases

A provider flags a case when a document looks altered, a face does not match, a name hits a sanctions or PEP list or a risk score crosses a threshold. The queue in the back office should show why, with the provider's evidence attached, so a compliance officer can approve, reject or request a new document in one action. Requests to the client go out as emails and portal notifications with the reason in plain language; a client told exactly what to re-upload usually does it the same day.

After onboarding: keeping KYC current

Verification does not end at the first approval. Identity documents and proofs of address expire, clients move, and a client whose activity grows may need checks that were not required at sign-up. RedCherry stores documents on the client's profile with expiry reminders, so the team and the client hear about an expiring document before it lapses, and the client uploads the new one in the portal or the app. Decide in advance what an expired document means for the client's permissions, and apply it the same way to everyone.

Choosing a KYC provider

• Coverage of the identity documents and countries your clients actually come from
• AML, sanctions and PEP screening included in the check, with clear match explanations
• Speed of automated decisions and how flagged cases are explained to your team
• A capture flow that works on a phone camera, since many clients verify on mobile
• Price per check, and what counts as a separate check when a client retries

RedCherry integrates Sumsub, Shufti Pro and Didit; another provider can be connected as a custom integration if your licence or your markets call for it.

What an auditor usually asks for

• A sample of client files with their documents and the provider's result for each check
• The approval history: who approved, rejected or requested a document, and when
• The written policy behind your verification levels and how the system enforces it
• How long flagged cases waited for a decision, and how exceptions were handled
• Who on the team can approve a client, and how that access is controlled

Each of those comes from records RedCherry keeps anyway: documents and results on the profile, decisions in the audit log, and access set by roles and permissions in the back office. Preparing for an audit becomes a set of exports rather than a project.

Referred and high-value clients

Clients who arrive through an introducing broker pass the same checks as everyone else; a partner relationship is not a reason to relax a rule. At the other end, clients who deposit large amounts or trade heavily may warrant an enhanced level, with source-of-funds evidence or extra screening. Applying that level by risk score rather than to every client keeps the heaviest checks where they are justified and the sign-up light for everyone else.

Whatever the level, the reason for a check should be recorded with it. When a high-value client asks why they were asked for more than a friend was, support can explain the rule; when an auditor asks why one client was treated differently, the risk score and the decision are on the same record.

Writing requests clients act on

Much of the delay in KYC comes from requests the client does not understand. 'Your document was rejected' produces a ticket; 'The photo of your passport is blurred at the bottom. Please upload a new photo in good light, with all four corners visible' produces a new upload, usually the same day. The difference is a specific reason and a specific action.

Write a short template for each common reason, a blurred photo, an expired document, a name that does not match, a proof of address older than allowed, and use them for every request. They go to the client as an email and a portal notification, and the same wording appears on the client's profile, so support can repeat it word for word when the client calls.

Review the funnel, not just the policy

• Where do applications stall: upload, provider review or manual queue?
• How long does a flagged case wait for a decision?
• Which countries have the highest rejection rates, and why?

Those three numbers, read monthly from the dashboard, tell a brokerage whether KYC is doing its job or just slowing clients down.