Adding Cross-Border Remittance to Your Payment Business: Build, White Label or Own the Code

A payment business that adds cross-border remittance is not adding a feature. It is taking on a new regulated activity, with its own permissions, its own compliance obligations and a new set of partners on the far side of the transfer. The businesses that do it well treat it as a new product line with its own controls. The ones that struggle treat it as another payment method.

This guide is for established payment businesses: payment service providers, wallets, neobanks and payroll providers. It covers your three options, what you must still hold whichever you choose, the compliance you inherit and the compliance you add, the integration questions to settle early, and a phased launch. Where RemitSo is relevant we say what it provides and what your team still does.

In domestic payments you usually know both ends of the transaction: a cardholder and a merchant, an employer and an employee, two account holders at regulated banks. In remittance, the recipient may be a person you have never onboarded, in a country with different sanctions exposure, paid out by a partner you depend on for confirmation.

Four things change as a result:

• Two people to screen, not one. Every sender and every recipient needs checking against sanctions lists, and recipients change often.
• FX becomes part of your price. Your customer sees a rate, a fee and an amount received, and your margin sits in all three.
• A payout leg you do not control. A partner in the receiving country pays the money out. When it fails, you need to know whose side the fault was on.
• New reports. Many regulators expect specific reporting on international transfers, separate from what you already file.

No software choice changes who is regulated for the activity. Before you compare platforms, establish whether your current licence or authorisation covers sending money across borders on behalf of customers, in each market where you want to offer it.

In many jurisdictions, a payment or e-money authorisation does not automatically cover money remittance, or covers it only within limits. You may need to extend your permissions, apply for a separate licence, or operate under a licensed partner's permissions. Each route changes who holds the compliance obligations, who your regulator holds accountable and what your contracts must say. Take advice from your regulator and counsel in each market. For specific markets, see our guides to UK licensing requirements and US money transmitter licences.

Whatever the route, you will usually still need:

• A named person responsible for anti-money laundering compliance for the remittance activity.
• A risk assessment covering the new corridors, customer types and payout methods.
• Policies for screening, limits, enhanced due diligence and suspicious activity reporting.
• Safeguarding or settlement arrangements for customer money in transit, and a bank willing to support the activity.
• Contracts with payout partners in each receiving country.

Build it yourself

You already have engineers who understand payments, so building looks natural. The hard parts are not the screens. They are sanctions screening and re-screening, risk rules your compliance team can change without a release, deposit matching, payout reconciliation, a double-entry ledger that handles FX, regulator reports, and an integration for every payout partner. Each must be built, audited and maintained. Building makes sense when remittance is central to your strategy and you can fund a dedicated team for years, not months.

White label with your brand

You run a ready-made remittance platform in your own brand: customer apps, admin panel, compliance controls and ledger. Your team configures corridors, fees, rates and rules rather than writing them. You depend on the vendor's roadmap, so check how releases are tested and published, and whether you can influence what is built.

Own the code

You buy the source code of an existing platform and run it as your own. You start from working software, but changes, upgrades and fixes become your engineering team's job unless you contract for support. This suits businesses that need deep integration with their own systems, independence from a vendor's roadmap, or protection if the vendor stops trading.

For a detailed cost comparison, see the true costs of building versus white label, and patchwork versus one platform on why stitching separate tools together rarely saves money.

Many businesses start with white label and keep the option to buy the code later, once they know how much remittance matters to them. If that is your plan, ask at the start what the route from one to the other looks like.

Integration is where an existing payment business differs most from a new operator. You already have customers, sign-in, identity data and money. Settle how each will connect before you commit. Frame each as a question to the vendor and get the answer in writing.

• Customers. Will remittance customers use the vendor's apps in your brand, your own app, or both? If your own app, what does the vendor's API cover and is its documentation generated from the deployed system?
• Identity. Can identity checks you already hold be reused, or must customers verify again? When does verification happen: at sign-up or inside the first transfer?
• Funding. Which of your payment routes can fund a transfer? If you hold balances, can a transfer be paid from a wallet where your licence allows?
• Status. How will your systems learn that a transfer was paid, held or returned? How are webhooks signed and retried, and can you see what was sent?
• Money and books. How do remittance entries reach your finance system? Is there a ledger you can reconcile, or only a transaction export?
• Environments. Is there a staging environment that behaves like production, and are releases tested there first?

Our guide to evaluating a remittance API covers these in depth, with a two-week plan your developers can run.

You are not starting compliance from scratch. Your existing programme gives you a base, but remittance adds obligations that a payments programme rarely covers.

Before launch, update your business-wide risk assessment, and decide who on your team rules on screening hits and holds for the remittance product. If it is the same team as your payments compliance, make sure they have the capacity and the training.

The safest launch limits the variables. Move to the next phase only when the one before meets the exit test you set in advance.

1. Foundations. Permissions confirmed, policies updated, bank and payout partner agreements signed, staff trained. Exit test: compliance sign-off.
2. Staging. Corridors, fees, rates and rules configured; test transfers run end to end, including failures, refunds and duplicate payments. Exit test: every test case passes and finance can reconcile them.
3. Pilot. One corridor, one payout method, a small invited group, such as your own staff or a set of long-standing customers. Exit test: transfers complete, holds are explained, the books reconcile.
4. Controlled growth. Open the corridor to more customers and add payout methods one at a time. Exit test: alert volumes and support contacts are within what your team can handle.
5. New corridors. Add corridors one by one, each with its own risk assessment and fees.

The business and figures here are illustrative, not drawn from any real company. A payroll provider pays workers for a few hundred employers. Many of those workers send part of their wages home each month, using a separate service. The provider decides to offer remittance in its own brand.

Permissions. Counsel confirms its payment authorisation does not cover remittance in its home market. It applies to extend its permissions and does not set a launch date until that is granted.

Option. Remittance is a new line, not the core business, and the engineering team is fully committed to payroll. It chooses white label and asks in writing how it could buy the code later.

Costs. The provider expects about 3,000 completed transfers a month by the end of the first year. Using RemitSo's published tiers, that falls in the 2,501 to 5,000 band at $499 a month, about 17 cents of platform fee per transfer, plus the $7,999 one-off setup fee and AWS hosting billed directly to the provider. There is no revenue share, so the provider's own fees and FX margin are not affected by the platform cost.

Pilot. It launches one corridor to bank accounts for 200 invited workers at three employers. In the first fortnight, two transfers are held for documents because the senders passed a limit tier; both customers upload them in the app and the transfers complete. One payout fails on the partner's side and the alert says so, so support contacts the customer before the customer calls.

RemitSo is a white label remittance platform with optional source code ownership. For a payment business adding remittance, it provides:

• Customer apps for iOS, Android and web in your brand: customers see the rate, the fee and exactly what arrives before they pay.
• Identity checks inside the first transfer, resumable if unfinished, with more documents requested as a customer's total grows.
• Screening of every sender and recipient against 8 sanctions lists, reloaded nightly, with re-screening when lists change.
• 46 risk indicators your team combines into its own rules: risky transfers wait for a person, everything else flows.
• A double-entry ledger written automatically, with deposits matched to the cent and payouts locked once approved, so your finance team can reconcile remittance alongside the rest of the business.
• Wallets where your licence allows, an optional add-on, with balances that cannot go below zero and funding only after identity is verified.
• Live API documentation for the Client API, served from the deployed system, plus logs of every partner call and webhook.
• Published pricing with no revenue share, a dedicated AWS account in your region, and the option to own the source code. See white label pricing and source code pricing.

Your team still holds the licence or permissions, makes the compliance decisions, manages bank and payout partner relationships, and supports your customers. See getting started and the admin features, or book a demo.