The Data Migration Checklist for Money Transfer Operators: Customers, Recipients, KYC, Balances and History

When an operator changes platform, customers notice the app, but the regulator, the auditor and the finance team notice the data. A missing KYC decision, a recipient that no longer passes validation or an opening balance that is out by a small amount can each cause more trouble than a week of downtime. The way to avoid that is unglamorous: list every data domain, decide how each will be checked, name an owner, and refuse to call anything "migrated" until the evidence says so.

This checklist is for the COO, CTO, head of compliance and finance lead of an established money transfer operator. It goes domain by domain, then covers mapping states, proving completeness, handling data that will not map, and record keeping. For how the move itself is staged, see the companion piece, migrating off a legacy remittance platform without losing customers.

Before any extraction, agree a single table. It forces the questions that otherwise surface on launch day: who decides whether a record is correct, and how they will know.

A customer record without its KYC is a customer you will have to ask again for documents, which is the fastest way to lose an established customer. Treat the profile, the documents and the decisions as one unit.

• Profiles: names, date of birth, address, contact details, status (active, suspended, closed) and customer group. Find duplicates before migration, not after; a legacy platform often holds the same person twice.
• Names: check how the old platform stored them. One free-text field split into first, middle and last names is a frequent source of later screening and payout mismatches.
• Documents: files, types, issue and expiry dates, and which documents satisfied which threshold.
• Decisions: approved, rejected and why, who decided and when, and any reviewer overrides with their reasons. A document without its decision is evidence without a conclusion.

Also carry each customer's running totals where your limits are counted over a period, such as 90 days or a year. If those totals reset to zero on migration day, a customer near a threshold can send more than your policy allows without being asked for documents.

Recipients are where migrations quietly fail. The old platform may have accepted details the new platform's payout channels, or the partner behind them, will refuse: a bank code in the wrong format, a mobile number without its country code, a cash pickup recipient with one name field where the partner wants two.

Run every migrated recipient through the new platform's validation for the payout method it is attached to, before customers see it. Sort the failures into three groups: fixable by rule (adding a country code), fixable by the operations team from other records, and needing the customer. The last group should be small and contacted in advance, not discovered at the moment the customer tries to send.

Two platforms rarely describe a transfer's life in the same way. The old one may use a single status for a whole transfer; the new one may track the customer's payment, the payout to the partner and the overall transaction separately. A label that looks the same ("pending") can mean different things on each.

Historic transfers are closed, so a mapping error there mostly affects reports and receipts. It still matters: regulatory reports and complaint responses will be built from this history.

Wallet balances

Where your licence allows wallets, each customer's balance is customer money. Agree every balance, and the total, to the cent, against the old platform and the safeguarding account. Freeze wallet activity for the shortest possible window around the moment balances move.

Transfers in flight

The cleanest rule is that a transfer finishes on the platform where it started. List every open transfer at the migration point, with an agreed outcome for each: completed on the old platform, refunded, or, only by explicit decision, recreated on the new one with a link to the original.

Ledger opening balances

The new ledger starts from opening balances: customer funds held, partner prefunding, fee income to date, suspense items. Post them as dated, explained journal entries mapped to the new chart of accounts, agree the trial balance with the old system and the bank, and have finance sign it. Every later reconciliation depends on this one.

• Sanctions decisions: who matched what, what the officer decided and why. Without them, cleared customers are raised again and compliance re-does work it has already done.
• AML rules: limits per corridor and period, document tiers, exceptions. Compare rule by rule, then run test customers through both and confirm the same outcome.
• Watched lists: internal watched names, email addresses, domains and high-risk countries.
• Open cases: investigations and suspicious activity work in progress, with their notes.

Any deliberate change to a rule during migration should be a recorded compliance decision, not a side effect of mapping.

For pricing, the test is simple: the same customer, corridor, payment method and amount should produce the same quote on both platforms, unless you have decided otherwise. Build a quote grid across amount bands and customer groups and compare it line by line. Keep the old rate history; complaints and audits ask what rate applied on a past date.

For staff, do not copy old roles blindly. Legacy platforms accumulate access nobody remembers granting. Rebuild roles from what each job needs, have each department head confirm their team's access, and remove leavers before migration rather than after.

Each method catches a different failure, so use all three:

1. Counts per record type and status catch missing records.
2. Totals per currency and month catch wrong amounts and duplicates that counts miss.
3. Samples checked by hand catch records that are present and add up but are wrong, such as a name split in the wrong place. Choose some at random and some deliberately awkward: closed accounts, rejected KYC, refunded transfers, long names.

Keep the reconciliation pack: queries used, results, differences, explanations and sign-off. It is the evidence that the migration was complete.

Some records will not fit: free-text notes, fields the new platform has no place for, records from a corridor you closed years ago. Options, in order of preference:

• Map with transformation, documented, where meaning is preserved.
• Attach as a note or document to the customer or transaction, so it stays visible.
• Archive in a secure, searchable, read-only store with a reference from the new platform.

Never silently drop a record. Every exclusion goes on a list with a reason and an approver.

Anti-money-laundering rules in most jurisdictions require customer due diligence and transaction records to be kept for a set period, commonly at least five years after a relationship ends or a transaction completes. Changing platform does not reset that clock. Whatever does not move to the new platform must remain retrievable for the full period, in a form you can hand to a regulator promptly. Check the retention rules for each licence and data protection obligations on how long, and no longer, data may be kept.

The numbers below are illustrative, chosen to show the reasoning rather than describe any real operator.

An operator with around 40,000 customers on three corridors migrates. Counts agree for customers, but a sample of 100 finds 6 duplicates the old platform had merged by display only; 312 duplicate pairs are found in total and resolved before launch. Recipient validation fails 1,140 of 61,000 records: 900 are fixed by adding country codes, 170 from other records, and 70 customers are contacted ahead of time. Transaction totals for one month differ; the cause is 18 "completed" transfers that the partner had returned, mapped to the wrong state and corrected. Opening balances agree after one suspense item is explained. Two retired AML exceptions are dropped by recorded compliance decision. The pack is signed and filed.

RemitSo is a white label remittance platform with optional source code ownership. When an operator moves to it, RemitSo migrates the data; the operator then runs a trial, and its own parallel run if it wants one, before a focused launch and the move of everyone else. Several parts of the platform make the checks above easier.

• Payout channels define the recipient details they require, with validation, including one, two or three name fields per channel, so recipients that would fail are found before a customer sends.
• Payments, payouts and transactions carry their own states and transitions, so legacy statuses can be mapped precisely.
• Double-entry ledger with a chart of accounts: entries are never edited, corrections are reversals, and any balance opens to the entries behind it, so opening balances can be traced.
• KYC documents reviewed, approved or rejected with labels, and sanctions rulings kept per person, so a cleared name is not raised again.
• AML rules import and export, with history of changes and who last changed each rule, so settings can be compared and evidenced.
• Watched names, emails, domains and high-risk countries import and export, each with its own access rights.
• Rates upload by CSV, Excel or JSON with full history, and a fee rule is required before a corridor can go live.
• Roles built from 89 permissions, each described in plain language, so access is rebuilt from what jobs need.

Your team still owns the evidence: agreeing counts and totals, checking samples, signing off opening balances, deciding what will not map and keeping archived records retrievable. See RemitSo for enterprise and the admin features.