Enhanced Due Diligence Only When It's Needed: Risk-Based Document Requests That Keep Good Customers Sending

Money transfer operators lose good customers at the moment a compliance step arrives that the customer did not expect and cannot see a reason for: a request for a payslip on a routine transfer home, or an account frozen until a bank statement is emailed to a generic inbox. Enhanced due diligence is necessary, but applying it to everyone is a weaker control, not a stronger one. It buries the transfers that deserve attention under paperwork from the ones that do not.

This guide is for compliance heads and MLROs who want document requests to follow risk: asked for when a customer's totals, behaviour or profile justify it, and not before. The approach applies on any platform; where RemitSo handles a step, we say so.

A blanket policy asks every customer for the same documents at sign-up. It is simple to explain and audit. Its costs show up later.

• Drop-off at the start. A new customer sending a modest amount to family has little reason to dig out a payslip. Many will not, and they go elsewhere.
• Review fatigue. When every file contains the same stack of documents, reviewers learn to skim. The one document that matters gets the same glance as the hundred that did not.
• Stale evidence. A proof of address collected at sign-up says little about a customer whose sending pattern changed two years later.

A risk-based policy asks for more as the risk rises. Risk rises in two ways: through totals, as a customer sends more over a period, and through signals, as their profile or behaviour matches something you have decided to watch. A sound design uses both. Totals give you a predictable, explainable ladder. Signals catch the customer who stays under every threshold but behaves in a way the thresholds were never meant to cover.

Your risk assessment should already say which corridors and customer types carry more risk. The task is to turn it into rules a platform can enforce.

A tier is a threshold plus the documents required once a customer crosses it. A window is the period over which the customer's total is counted. Getting both right is most of the work.

Choose windows that match the risk you are measuring

Different windows catch different behaviour. A single-transaction check catches one large transfer. A one-day window catches a customer splitting a large amount into several smaller ones on the same afternoon. A one-month or 90-day window catches a steady build-up. A one-year window catches the customer whose annual total is out of line with their stated occupation, even though no single month looks unusual.

Run at least three at once: per transaction, a short window for structuring and a long one for cumulative exposure.

Set tiers per corridor, not just per customer

The right threshold for a low-risk corridor is rarely right for a corridor your risk assessment rates higher. Set a default for each sending currency and paying country, then add exceptions for specific payout countries where you want stricter or different requirements.

The table below is an example of one policy. Every figure in it is illustrative, chosen to show the structure rather than to recommend levels; your thresholds should come from your own risk assessment and the rules of each licence you hold.

Three design points matter more than the exact numbers. First, each tier should ask for one new thing, so the customer meets a short request rather than a wall. Second, the documents should match the question the tier is asking: a long-window tier is about means and source of funds, so asking for another proof of address there adds paperwork without adding assurance. Third, tiers should be cumulative: a customer at the one-year tier has already provided what the lower tiers asked for.

Totals are predictable, which is their strength and their weakness. A customer who learns your thresholds can stay under them. Risk indicators catch what totals miss.

Useful indicators fall into a few families:

• Geography: an identity document, payment details or sign-in IP address from a high-risk country or one on the FATF list of high-risk jurisdictions subject to a call for action.
• Identity consistency: profile and document data that do not match; the customer's name not matching the payment account holder; a possible duplicate customer.
• Behaviour: transfer frequency and volume, frequent transfers to the same recipient, linked transaction patterns, many different IP addresses, several payment methods, or payment details reused across customers.
• Lists and history: internal watchlists, watched names, emails and domains, sanctions checks, and whether a suspicious activity report has been filed before.

A single indicator rarely justifies enhanced due diligence. Combine indicators into rules with explicit conditions, and decide for each rule what happens next: hold the transfer, ask for a document, or both.

Hold, ask, or both

Holding a transfer and asking for documents are different tools. Hold when the risk is about this transfer: a likely sanctions match, a payment that looks like fraud. Ask without holding future activity when the risk is about what you know of the customer: their source of funds is undocumented for the amounts they now send. Do both when the transfer is unusual and the documentation is missing. Keeping those choices separate is what lets good customers keep sending while the file is completed.

A good request names one document, says why it is needed and what a usable version looks like. "We need proof of income because of the amounts you now send; a recent payslip with your name on it works" gets better responses than "Please upload supporting documentation".

Match the request to the concern:

• Where the money came from (source of funds): bank statements showing the funds arriving, a sale agreement, a payslip.
• Whether sending fits their means (source of wealth or income): payslips, employment letters, tax returns.
• Why they are sending: a purpose and relationship declaration, invoices for business payments, school or medical invoices where relevant.

When a document is rejected, tell the customer why in terms they can fix: expired, unreadable, wrong name. Rejection reasons from a fixed list also give you data: a run of "unreadable" in one corridor may point to poor upload guidance.

The most common failure in tiered document policies is not a bad threshold. It is a tier that asks for a document the customer has no way to provide. The policy says "proof of income above 10,000 over 90 days", but the app for that sending country offers no proof-of-income upload category. What happens next depends on the platform. On some, the transfer is blocked with no route forward and the customer leaves. On others, the requirement is quietly skipped and the transfer goes through with less scrutiny than your policy promised.

The second is more dangerous, because nobody notices until an audit sample turns it up.

To close the gap:

1. For every tier in every corridor, list the document categories it can ask for.
2. For every sending country, list the document categories the app actually offers customers.
3. Compare the two. Each mismatch is either a missing category in the app or a tier that asks for something unrealistic.
4. Repeat the check whenever you add a corridor, change a tier or change the categories offered in a country.
5. Make sure the platform tells you when a mismatch happens in live traffic, rather than finding out from a sample.

The figures below are illustrative, used to show the reasoning rather than to describe any real operator or customer. They use the example tiers from section 02.

Month one: nothing to do

A customer signs up and sends 400 to a family member, then three more transfers of a similar size over the month. Identity and selfie were checked inside the first transfer. Their one-month total is well below the first threshold, and no risk rule matches. Every transfer flows without a person touching it. This is the point of the design: most customers should look like this, and compliance staff should never see them.

Month two: a tier is reached

Over three weeks the customer sends 5,600 for a family medical bill, crossing the one-month tier. The platform asks for proof of address inside the app. A cropped utility bill is rejected with a label saying it is incomplete; a full copy arrives the next day and is approved. No transfer was stopped.

Month three: a signal, not a total

The customer's 90-day total is now near, but under, the 10,000 tier. Then a risk rule matches: a transfer is funded from a card issued in a different country from the customer's sign-in IP, to a new recipient who also receives from two unrelated senders. The rule places the transfer on hold for manual review and raises the customer's risk score.

The card belongs to the customer's spouse, which explains the country difference, but the recipient pattern needs an answer. Rather than refusing the transfer, the analyst requests a purpose declaration inside the app. The customer explains the recipient is a clinic paid by several families and uploads its invoice. The analyst approves the transfer and records the reasoning.

What the design achieved

The customer met two requests and one short hold, each with a reason. A blanket policy would have asked for everything at sign-up and still missed the recipient pattern, because no threshold was crossed.

A risk-based policy is only defensible if you can show it working. Expect an examiner to ask for four things.

• The policy as it stood on a given date, and who changed it since.
• Why each enhanced check happened. For a sample of customers, which tier or rule triggered the request.
• What was asked, received and decided. Each document, whether it was approved or rejected, the rejection reason, and who decided.
• What happened to held transfers. Who reviewed each one, what they concluded, and how long it took.

Record the reason for each threshold change. "Lowered the one-day tier after a quarter of structuring alerts" turns a change log into evidence. Plan the change as well as record it: if a new tier applies at once, customers already past the new threshold will be asked for documents on their next transfer, so count them first and brief support before you save.

RemitSo's admin panel gives compliance teams the controls described above. Your team still writes the policy, sets the thresholds and makes every decision on a held transfer.

• AML rules per currency, paying country and payout country, with corridor exceptions: one default per route, with stricter requirements where your risk assessment calls for them.
• Policy windows for every transaction, past 1 day, 1 month, 90 days and 1 year: structuring, build-up and annual exposure are each measured, not just single transfers. Period limits, per-transfer caps and calendar windows are enforced exactly as set.
• A new rule applies at once: no waiting for a batch or a release, so a tightened tier protects you from the moment it is saved. Plan for the customers it newly asks for documents.
• Tiers that name the documents asked for as totals grow: customers are asked for one thing at a time, at the point it becomes relevant.
• Every rule change reviewed before saving and kept as history, with who last changed each rule: you can show an examiner what the policy was on a given date and who changed it.
• A whole rule set moves between installations as a file: test a policy on staging, then import the same file to production, so what was tested is what goes live.
• On-demand KYC (January 2026 release): when a transaction is flagged for EDD, your team requests documents inside the app rather than stopping the customer cold, so good customers keep a route forward.
• 46 risk indicators combined into your own risk rules: risky transfers wait for a person; everything else flows on its own.
• Customer KYC documents reviewed with rejection labels: customers learn what to fix, and you can see which reasons recur by corridor.
• Plain-language alerts, including "High customer risk score detected", "Transaction placed on hold" and "Transaction under manual review", sent to the people subscribed to them. The alert "AML policy asked for a document the corridor cannot collect" fires when a transfer was not held because the customer's country offers no such document category, which means less scrutiny than you intended. The fix is to correct the country's category or the tier.
• Compliance Dashboard: the programme in one view, with each part granted separately by role.

See the full list on the admin features page, read the release notes, or book a demo to walk through a policy with your own corridors.

• FATF: Guidance for a Risk-Based Approach for Money or Value Transfer Services (2016)
• FATF: The FATF Recommendations (Recommendations 1 and 10 and their interpretive notes)
• FATF: High-risk and other monitored jurisdictions (call for action and increased monitoring lists)

Checked October 2026. Regulations change; confirm current requirements with the regulator or your adviser.