Most problems with a new sending country do not show up on launch day. They show up when the first customer tries to verify with a document the platform does not offer, or when a regulator asks why a field that should have been collected is blank for every customer in that market. Both trace back to the same place: the country's setup. Documents, onboarding fields and the lists behind them are dull to configure and expensive to get wrong.
This guide is for compliance and operations leads at established operators adding a sending country, or tidying up one that has grown without a clear owner.
RemitSo is one way to run this. Its Demography module holds each country's document categories and types, customer onboarding fields, transaction purposes, relationships, sources of funds, salary ranges and states; its Glossary holds the codes behind them. A Sending Countries check and an alert catch a country that customers cannot verify in. It does not decide what your licence requires: your compliance team still chooses the documents, fields and wording. This guide sets out how to make those choices well on any platform.
Choose the documents each country can actually offer
Identity documents are national. A document type that most customers in one country carry may not exist in another, and a residence permit category that matters in one market is irrelevant in the next. Set documents per country, in two layers.
- Categories: what the document proves, such as identity, address or source of funds.
- Types: the specific documents accepted in that category for that country, such as a passport, a national identity card or a residence permit.
Three checks before a country goes live:
- Can a typical resident prove identity? At least one type in the identity category that most of your target customers hold.
- Can every document your AML tiers ask for be collected? If your rules ask for proof of source of funds above a threshold, the country needs a type in that category.
- Are the types named the way customers know them? A customer choosing from a list will pick the name on their card.
The second check matters more than it looks. In RemitSo, customers are not held for a document their country cannot offer, and the "AML policy asked for a document the corridor cannot collect" alert tells your team when a rule and a country's setup disagree. Better to find that in setup than from a stuck customer. For how to design the tiers themselves, see enhanced due diligence only when it is needed.
Rule of thumb: for every document your AML rules can ask for, there should be at least one accepted type in every sending country those rules cover. Check it as a matrix, not one country at a time.
Load the onboarding fields customers must complete
Onboarding fields, or customer attributes, are what you ask a customer during sign-up and verification: name parts, date of birth, address, occupation, and anything else your licence or your risk approach requires in that country. They differ by country for good reasons. Address formats vary, some markets need a state or province, and naming conventions differ.
Set them per country
Asking every customer everything makes onboarding slower and adds nothing. Asking too little leaves gaps that surface in a regulatory report or an examination. Decide per country which fields are required, which are optional, and which do not apply.
Load many countries from a file
Typing fields into each country by hand is where inconsistencies creep in. In RemitSo, customer onboarding fields for many countries load from a file, with a preview before anything is saved, and an upload never removes anything. That last point matters: a file that leaves out a country or a field cannot quietly delete it, so a partial file is safe to load.
Watch for: name fields. If a country's setup leaves no way for a customer to give a name, they can sign up but cannot be verified properly. RemitSo's Sending Countries check looks for exactly this.
Set the lists behind the questions
Several onboarding and transfer questions are answered from lists: why the customer is sending, who the recipient is to them, where the money came from. These lists feed monitoring, investigations and regulatory reporting, so they deserve the same care as documents.
- Transaction purposes: family support, education, property and so on. Too few and every transfer becomes "family support"; too many and customers pick at random.
- Sender–recipient relationships: the relationship gives an analyst context when a pattern looks unusual.
- Sources of funds: salary, business income, savings, sale of property. These should line up with what your source-of-funds document category can prove.
- Salary ranges: set per currency, so a declared income band means something in local terms. In RemitSo, salary ranges are used for risk assessment.
- States and provinces: a fixed list gives cleaner addresses than free text, which helps screening and reporting.
In RemitSo, purposes, relationships and sources of funds are set per country, so each market offers the choices that make sense there.
Keep the codes consistent in one glossary
Behind every list sits a code. Reports, exports and rules use the code, not the label a customer sees. If two countries use different codes for the same purpose, every report that groups by purpose is wrong.
RemitSo's Glossary holds the definitions and codes in one place: purposes, relationships, occupations, honorifics, sources of funds, cancellation reasons, document rejection labels, customer groups, suspicious behaviours, suspicious activity labels, account closure reasons and option lists. Practical habits:
- Agree codes before labels. Labels can be reworded; codes should stay put once reports depend on them.
- Write rejection labels for the customer. "Image blurred, please retake in good light" gets a better second attempt than "Rejected".
- Review closure and cancellation reasons yearly. If "Other" is the most used, the list is not doing its job.
Check the country before customers find the gap
The cheapest moment to find a setup gap is before the first customer arrives. In RemitSo, the customer's ID check and selfie happen inside the first transfer, not at sign-up. That is good for conversion, but it means a missing document type surfaces when the customer is ready to pay, which is the worst moment to discover it.
RemitSo's Sending Countries check catches a country where a customer could verify with no name or could not complete proof of identity, and raises the "Sending country not set up for customers" alert. Alerts reach only the people subscribed to them, so name an owner when the country is set up.
Withdraw a document type properly
Countries change their documents. A card format is replaced, a permit category is abolished, or your compliance team decides a document is no longer reliable. Hiding it from a menu is not enough if it can still be submitted another way.
In RemitSo, disabling a KYC document type really withdraws it: it stops being offered. A deleted type can be restored. Both ask for a reason, which is kept and written to the audit log, so a later reviewer can see why the change was made. Before withdrawing a type, check that another type in the same category remains, or customers in that country will be unable to verify.
Withdrawing an approval on an individual customer's document is a separate decision. It needs a reason too, and before confirming, the screen says how many transfers will be sent back to ask for a replacement. See rescuing stalled onboarding for that side of the work.
Work through the country setup checklist
| Item | Why it matters | What breaks if missed |
|---|---|---|
| Country activated, with its currency | Customers can select it at sign-up | The market simply is not available |
| Identity document category and types | Customers can prove who they are | Customers sign up but cannot complete their first transfer |
| Every category your AML tiers ask for | Higher-tier documents can be collected | Customers stall at a threshold; the corridor cannot collect what the rule demands |
| Onboarding fields, including name parts | Profile matches the documents and reports | Customers verify with incomplete data; reports show blanks |
| Purposes, relationships, sources of funds | Context for monitoring and investigations | Analysts have nothing to compare a pattern against |
| Salary ranges in local currency | Declared income is meaningful for risk assessment | Income bands that make no sense locally |
| States and provinces | Clean, consistent addresses | Free-text addresses that screen and report poorly |
| Glossary codes agreed | Reports group correctly across countries | The same purpose counted under two codes |
| Owner subscribed to the setup alert | Gaps reach a person | The alert fires and nobody reads it |
Corridors opened from the new country still need their own fee rule: in RemitSo, no corridor can be activated without one, even when no fee is charged.
Scenario: adding a second sending country
The details below are illustrative, chosen to show the reasoning rather than to describe any real operator or market.
An operator that has sent from one country for several years adds a neighbouring country. Its AML rules ask for identity at the first transfer and proof of source of funds once a customer's total over 90 days passes a threshold.
Step 1: documents
The compliance lead adds an identity category with three types: passport, national identity card and residence permit. Running the documents against the AML tiers as a matrix, she notices no source-of-funds category exists for the new country. Without it, the first customers to reach the threshold would be asked for something they cannot upload. She adds the category with payslip, bank statement and tax return.
Step 2: onboarding fields
The operations lead prepares one file with the new country's fields. The preview shows 14 fields to add and none removed. The file omits the home country entirely, which is fine, because an upload never removes anything.
Step 3: lists and codes
Purposes and relationships are copied from the home country with the same Glossary codes, so reports group both countries together. Two purposes are dropped as irrelevant, and salary ranges are set in the local currency.
Step 4: the check
The Sending Countries check flags the country. The name fields loaded from the file were marked optional by mistake, so a customer could verify with no name. The fix takes a minute. The operations lead subscribes to "Sending country not set up for customers".
Step 5: three months later
One accepted card format is withdrawn by the issuing country. The compliance lead disables the type, records the reason, and confirms the other identity types remain. Customers are no longer offered it, and the audit log shows why.
Takeaway: each gap in this scenario would have reached a customer as a failed verification. Found in setup, each one took minutes.
Doing it with RemitSo
RemitSo's Demography and Glossary modules hold a sending country's setup in one place. See the admin features and how verification looks to customers in the customer app.
- Document categories and types per country (both): customers are offered documents they actually hold, and your team sets exactly what each market accepts.
- Onboarding fields loaded from a file with a preview (your team): many countries set up at once, a preview before saving, and an upload never removes anything, so a partial file is safe.
- Purposes, relationships and sources of funds per country (both): customers choose from options that make sense where they live, and analysts get consistent context.
- Salary ranges per currency and states per country (your team): declared income means something locally for risk assessment, and addresses are cleaner for screening and reporting.
- Glossary codes in one place (your team): purposes, rejection labels, closure reasons and other codes stay consistent, so reports group correctly across countries.
- Sending Countries check and alert (both): a country where customers could verify with no name or could not prove identity is caught and reported to a named person, before customers are locked out.
- Customers not held for documents their country cannot offer (both): customers are not asked for the impossible, and the "AML policy asked for a document the corridor cannot collect" alert tells your team where a rule and a country disagree.
- Withdrawing a document type for real (your team): disabling stops it being offered, a deleted type can be restored, and both keep a reason in the audit log, which is what an examiner asks for.
What your team still does: decide which documents, fields and lists your licence and risk approach require in each country, and keep them current as countries change their documents. To talk it through, book a demo.
Frequently asked questions
Should every sending country have the same onboarding fields?
No. Keep the codes and the core fields consistent so reports work across countries, but set required fields per country. Address formats, naming conventions and local requirements differ.
What happens if our AML rules ask for a document a country cannot provide?
In RemitSo, customers are not held for a document their country cannot offer, and an alert tells your team that the rule and the country's setup disagree. Your compliance team then decides whether to add a document type or adjust the rule.
Is it safe to load onboarding fields from a file into a live system?
In RemitSo, yes, within limits: you see a preview first, and an upload never removes anything. Review the preview carefully, because additions and changes still take effect.
Why keep a reason when disabling a document type?
Because months later someone will ask why customers in that country can no longer use it. A reason in the audit log answers that without relying on anyone's memory.