Designing a KYC review workflow for a forex brokerage

A client uploads a passport scan on Thursday evening. On Monday morning a sales agent calls to ask why they have not deposited yet, while the file is still sitting in a compliance inbox. Nobody made a specific mistake. Nobody knows where the request stands or whose move it is.

The short answer: a working KYC review workflow rests on five decisions you write down in advance. What you ask the client for, and when. Who reviews, and in what order. What a decision looks like (a status and a reason). What the client may do while waiting. What gets recorded, and what reopens a file.

QUANTIX publishes this guide, and we sell a brokerage CRM and back office that includes a KYC queue, so we have a commercial interest in the subject. The workflow below is written to work in any system; QUANTIX appears only in the last section. This is not legal advice: the verification rules themselves come from your regulator and your compliance officer.

Policy first, workflow second

A workflow does not create rules; it carries them out. Before anyone configures a screen, you need a written anti-money-laundering and customer-identification policy, approved by your compliance officer against your regulator's requirements.

Most regulators build on the same international baseline: the Financial Action Task Force (FATF) Recommendations. Recommendation 10 asks firms to identify the customer and verify that identity using reliable, independent sources, to understand the purpose of the business relationship, and to continue due diligence for as long as the relationship lasts, with the depth of each measure set by risk.

Without a written policy, the KYC queue quietly becomes the policy. Each reviewer approves or rejects on instinct, and nobody can later explain why one file passed and a near-identical one did not.

Define the statuses before you build the queue

The most common source of confusion is a single "pending" status that covers everything. Give each status one meaning, and make it obvious whose move comes next: the client's or your team's.

Status	What it means	Who acts next
Not submitted	Account open, KYC file empty	Client, with a reminder from sales
Awaiting review	Documents received, nobody has opened them	Compliance
More information needed	A document is missing or unreadable	Client
Approved	Verification complete under your policy	Nobody, until the next review
Rejected	A final decision not to accept	Compliance records the reason
Expired	A document has expired or a periodic review is due	Client, then compliance

Once you know who acts after each status, you can separate time spent waiting on the client from time spent waiting on your staff. That split is the most useful thing to measure at the KYC stage, as we explain in our guide to the client chain from first lead to first deposit.

Document intake: through the portal, not WhatsApp

Every document that arrives by email or WhatsApp needs someone to download it, re-upload it and attach it to the right client. That is where errors start: a passport in the wrong customer file, or a scan nobody can date.

Intake should give you:

• Uploads from the Trader Portal itself, with several files per submission, so the front and back of an ID card are two files rather than one stitched image.
• Clear instructions in the client's language before they upload: which documents you accept and what makes a scan unusable. Prevention is cheaper than rejection.
• A visible status card for the client, so they can see where their request stands without calling their sales contact.
• Re-upload of the failed document only, not the whole file again.

The review queue: order, ownership and separation of duties

When requests pile up, the question becomes which one gets opened first. Decide, and write it down. Oldest first is the fairest rule and the easiest to defend in an audit. If you choose to prioritise a category of request, put the criterion in the policy, so the client who chases hardest does not jump the queue.

The queue needs:

• Filters by status, date and assignee, and saved views for each reviewer.
• A review page that shows the document beside the client's data, so the reviewer can check name, date of birth and address without switching windows.
• Clear separation of duties. A sales agent benefits when their client is approved, so they should not hold KYC approval rights. They see the status and nudge the client; compliance decides.
• A second review for cases your policy rates as higher risk, if your policy calls for one, with both reviewers' names on the record.

For the wider question of what a CRM must do for each desk, from sales to dealing, see what a CRM for forex brokers must actually do.

A decision is more than approve or reject

A rejection without a reason sends the client back to square one and the sales agent back to the phone. Write a standard list of reasons the reviewer picks from, each with ready-made client wording in every language you serve. Typical reasons:

• The image is blurred or the edges are cut off.
• The document has expired.
• The name on the document does not match the account.
• The proof of address is too old or not in the client's name.
• A page or side of the document is missing.

Then separate two kinds of outcome. More information needed means the problem is fixable and the client can upload again. Rejected is a final decision compliance takes for a reason in the file itself, documented internally. Mixing the two fills the queue with rejections that only needed a short note.

Because the reasons are standardised, after a month you can see which ones recur. If most returns are blurred photos, the fix is better upload instructions in the portal, not another reviewer.

What can the client do while they wait?

This is a policy decision, to be made for every status. Can the client log in? Deposit? Trade? Withdraw? The answers depend on your regulator and your business model. The real problem is having no written answer, because then every employee tells the client something different.

Once the rules exist, automate the communication:

• A notification to the client on every status change, in their preferred language and on the channel they chose.
• A notification to compliance when a new document arrives.
• The same status visible to sales on the customer record they already work from. The agent can see the client is waiting on compliance and does not ask for the documents a second time.

The record, and when a file reopens

Every KYC decision must be able to answer four questions later: who decided, when, on which document, and what the status was before and after. A free-text note on the customer record is not enough. You need an audit trail that stores before-and-after values and can be filtered and exported.

FATF Recommendation 11 sets a floor for keeping customer due diligence records: at least five years after the business relationship ends. Your national rules may require longer, so build your retention policy on the longest period that applies to you.

Approval is not the end of the file either. Decide what reopens it:

• An identity document expiring. The system needs the expiry date to remind you and the client before it happens.
• A change in the client's details, such as address or name.
• A periodic review, at the frequency your policy sets for each risk level.

How to tell whether the workflow is working

Every week, ask the queue three questions:

1. How many requests are awaiting review, and how old is the oldest?
2. How much of the waiting time sat with the client, and how much with your team?
3. Which rejection or more-information reason comes up most often?

If the delay sits with your team, the fix is assignment or reviewer capacity. If it sits with the client, the fix is instructions and notifications.

What this guide does not cover

This guide does not cover how to screen against sanctions lists or identify politically exposed persons (PEPs), source-of-funds checks, risk-scoring models, or the document list a particular regulator accepts. Those belong to your compliance officer and legal adviser.

Where QUANTIX fits

In the QUANTIX brokerage CRM and back office, the KYC queue works on the same record that sales and finance use, as the platform overview explains. Specifically:

• In the Trader Portal, clients upload multiple documents, see a KYC status card and set their notification-channel and language preferences. KYC status reaches them the moment it changes.
• In the CRM, the KYC queue has filters and export, a review page with document preview, and approve, reject or create-and-approve. Every status change fires the notifications you configure.
• The customer record includes Documents, KYC and Audit Log tabs. The audit trail covers more than 70 event types with before-and-after values.
• Compliance Officer is one of the ready-made roles, and the permission matrix (19 modules, 6 actions, 4 data scopes) decides who sees the queue and who can approve.
• Notification triggers include KYC approvals, expiries and failures, with templates per language and channel, as described on the automation and integrations page.

To be clear: QUANTIX provides KYC and compliance tooling. Using it does not make your firm compliant or give it a licence, and the acceptance rules and rejection reasons are yours to set. The integrated providers do not include an automated identity-verification or sanctions-screening service; if your policy requires one, connecting a provider of your choice is assessed as custom development under a separate scope.

If you want to see the workflow run on your own cases, book a private demo and bring your current KYC policy and the rejection reasons you use today.