Opening a corridor is rarely hard because of one big decision. It is slow because of hundreds of small settings: rates for every amount band, the banks and mobile money operators in the payout country, the recipient details each delivery method needs, the limits and documents your AML policy asks for, and the fields a customer in a new sending country fills in. Typed one at a time, that is weeks of work and a long trail of typos. Loaded from files that have been checked once, it can be an afternoon.
This guide is for operations leads, compliance heads and CTOs preparing new corridors, new environments or a migration. It walks through each kind of file import, what it sets up, what can go wrong, and how to keep control of who can load and export what.
RemitSo is one way to run this. Its admin panel imports exchange rates, AML rules, watchlists, payout channels, delivery options and customer onboarding fields from files, each with its own safety net. Your team still prepares the files, checks what they contain and decides when a corridor goes live.
Decide what to type and what to load from a file
Typing in the console is right for small, considered changes: one rate, one rule, one bank. Files are right when the change is large, repetitive or needs to be the same in two places. Three signs you should be using a file:
- Volume: dozens of banks, bands or fields that follow a pattern.
- Review: compliance or treasury wants to check the whole set in a spreadsheet or document before it goes in.
- Repeatability: the same configuration must exist on staging and production, or in an old and new platform.
A file also becomes a record. The version you loaded on launch day is the version you can show an auditor, compare with next quarter's, or load again if something is changed by mistake.
Know what each import sets up and what protects you
| What | Format | What it sets up | Safety net |
|---|---|---|---|
| Exchange rates | CSV or JSON | Standard rates for every pair and amount band | Importing is its own permission; an import never removes a rate |
| AML rules | JSON | Policies, period limits, tiers and document requirements, moved between installations | Never removes what the file leaves out; every change kept in history; import is its own permission |
| Watched names, emails, domains, high-risk countries | File import and export | Internal watchlists used in screening and risk rules | Separate rights to see, add, change, remove, import and export each list |
| Payout channels | File (CSV or JSON) | Country, currency, delivery method, required recipient details and decimal places, many at once | A corridor cannot be activated until its fee rule is set |
| Delivery options | File, all countries at once | Banks and mobile money operators per payout country | One file for every country, so lists stay consistent |
| Customer onboarding fields | File | The fields customers fill in, per country | Preview before loading; an upload never removes anything |
Load exchange rates for a whole corridor at once
Rates are the import most teams use first. CSV opens in a spreadsheet with one rate to a row, which suits treasury preparing a new corridor's bands offline and a second person checking them. JSON is the document a new environment is set up from, which suits copying a tested rate set from staging to production.
Because an import never removes a rate, a file containing only the three new pairs adds those pairs and leaves every existing corridor alone. That makes a small, focused file the safest choice. For the vocabulary of buy, sell, spread and margin, and the checks to run on any rate set, see managing exchange rates without mistakes.
Move an AML rule set between installations
AML rules decide how much a customer may send in a period and which documents they must provide as their total grows. A rule set agreed with your compliance function is a significant piece of work; it should not be retyped from a policy document into each environment.
Export the rule set as JSON from the installation where it was built and tested, and import it into the next. Two behaviours make this safe:
- Import never removes what the file leaves out. A file containing rules for the new corridors adds or updates those rules only. Existing corridors keep theirs.
- Every change is reviewed before it is written. The review explains what each change means for customers, including any change that lets them send more. Nothing is saved until someone confirms.
Watch for: a rule set that asks for a document the new corridor cannot collect. If customers in a sending country cannot obtain a document your policy demands, transfers stall. Check document requirements against what each country can actually provide before importing.
Bring your internal watchlists with you
Most operators keep their own lists alongside the sanctions lists: watched names, watched email addresses, watched email domains and high-risk countries. These carry years of judgement from your compliance team and are easy to lose in a move.
Export each list to a file and import it into the new installation. Watched names are matched the way sanction screening matches, catching close spellings, other alphabets and a middle name added or left out, and people already on the books are checked as soon as a name is added. Keep the reason recorded against each entry: the reviewer sees it when a match appears, and a name with no reason is hard to rule on.
Load payout channels and delivery options in bulk
A payout channel is a country, a currency and a delivery method, with the recipient details that method requires and the decimal places the currency uses. A corridor with bank, mobile wallet and cash pickup needs three channels; three corridors need nine. Delivery options are the banks and mobile money operators customers choose from in each country, and some countries have long lists.
Both load from files. Payout channels can be set up one at a time or loaded many at once. Delivery options can be imported for all countries from one file, so the lists stay consistent everywhere.
Before loading, check the recipient details each channel requires against what your payout partner needs. A missing field becomes a rejected payout days later, which is far more expensive to fix than a column in a spreadsheet. For choosing partners and methods, see payout corridor strategy.
Set customer onboarding fields per country
Each sending country asks customers for slightly different things: address formats, identity numbers, occupation fields. Loading these per country from a file, with a preview before anything is written, lets you see exactly what customers will be asked. Because an upload never removes anything, adding fields for a new country cannot wipe the fields an existing country relies on.
Rule of thumb: prefer imports that only add or update. If a file can delete, one missing row becomes a production incident. If it cannot, the worst case is a field or rate you still need to add.
Treat JSON as the document a new environment is set up from
CSV is for people; JSON is for environments. A JSON export captures a configuration exactly, so it can be loaded somewhere else and produce the same result. That gives you three practical patterns.
- Staging to production: build and test the new corridors on staging, export the JSON, import into production. What customers get is what you tested.
- Migration: when moving from an older platform, the configuration that defines your corridors can be prepared as files and loaded, alongside the customer and transaction data. See the data migration checklist and migrating without losing customers.
- A known-good copy: an export taken before a large change is a reference point you can compare against, or reload from.
Control who can import and who can export
Imports and exports are powerful in opposite directions, so treat them as separate rights.
- Import changes many settings at once. Grant it to the few people who prepare and own each area: treasury for rates, compliance for AML rules and watchlists, operations for payout channels.
- Export hands sensitive settings to whoever holds the file. An AML rule set tells a reader exactly where your thresholds sit; a watched-names list contains personal data and your suspicions. Grant export sparingly, and decide where exported files may be stored and for how long.
- Do not combine them by default. Someone who needs to read a configuration for review does not need to load one.
Takeaway: an exported file is a copy of your controls sitting outside the console. Handle it like any other sensitive document.
Scenario: opening three new corridors in a week
The plan below is illustrative. An operator sending from Australia opens three new payout countries, each with bank and mobile wallet delivery. The partner connections are already in place.
Monday: prepare the files
Treasury prepares a CSV with the three new pairs and three amount bands each. Operations prepares six payout channels and the delivery options for the three countries. Compliance extends the AML rule set with limits and document tiers for the new corridors.
Tuesday: load and test on staging
Each file is imported into staging. The AML rules page and its history show only the new corridors changed; nothing else moved. The team sets a fee rule for each corridor by hand, because no corridor can be activated without one, even where the fee is zero. Test transfers run through each route.
Wednesday: fix what testing found
One mobile wallet channel was missing a recipient detail the partner requires. The file is corrected and reloaded. One document tier asks for something customers in that country cannot provide, so compliance changes it.
Thursday: move to production
Rates and AML rules are exported from staging as JSON and imported into production by the people who hold import rights. Payout channels and delivery options are loaded from the corrected files. Fee rules are set.
Friday: switch on and watch
The corridors go live. The team checks that no pair customers can send on is missing a rate, and watches alerts and Scout through the first transfers. The exported files are filed with the launch sign-off.
Doing it with RemitSo
On RemitSo a new corridor is a setting, not a project. File imports in the admin panel do the bulk of the work; see the admin features.
- Exchange rates from CSV or JSON: importing is its own permission and never removes a rate, so a file of new pairs leaves every existing corridor alone.
- AML rules as a JSON file: a whole rule set moves between installations; import never removes what the file leaves out, and every change is kept as history. Edits made on the page itself go through one review before anything is saved.
- Watchlists in and out: watched names, emails, domains and high-risk countries each import and export from a file, with their own rights to see, add, change, remove, import and export.
- Payout channels in bulk: set up one at a time or loaded many at once, each with its required recipient details and decimal places, so payout setup takes minutes rather than hours.
- Delivery options for all countries: banks and mobile money operators imported from one file.
- Onboarding fields per country: loaded from a file with a preview, and an upload never removes anything.
- Guardrails on go-live: no corridor can be activated without a fee rule, a pair customers can send on with no rate is flagged in red, and alerts such as "Sending country not set up for customers" and "AML policy asked for a document the corridor cannot collect" tell the right people what is missing.
Your team still prepares and checks the files, agrees the AML policy, connects and tests partners, and decides when each corridor opens. For migration from another platform, see RemitSo for enterprise or book a demo.
Frequently asked questions
Can an import delete settings we already have?
It should not, and on RemitSo the rate, AML rule and onboarding field imports never remove what the file leaves out. A file with only new corridors adds those corridors and leaves the rest alone.
When should we use CSV and when JSON?
Use CSV when people need to prepare or review figures in a spreadsheet, such as rates. Use JSON when you are copying a configuration exactly from one environment to another, such as staging to production.
Who should be allowed to export AML rules and watchlists?
Very few people. Exports hand your thresholds and watched names to whoever holds the file. Grant export separately from import, and set rules for where exported files are kept.
Can we set fees from a file too?
Fee rules are set per corridor in the console, and every corridor needs one before it can be activated, even when no fee is charged. Plan that step into your launch.
Do file imports help with migration from another platform?
Yes, for configuration such as rates, AML rules, watchlists, payout channels and onboarding fields. Customer and transaction data are a separate part of the migration, with their own checks.