Owning Your Remittance Source Code: Building Your Own Modules on a Proven Core

Most established money transfer operators reach a point where configuration is no longer enough. You have corridors, partners and a compliance programme that work. What you want next is something nobody else offers in quite your shape: a module for your agent network, a portal for business customers, a pricing engine that reflects how your market actually behaves. At that point the question changes from "which platform should we use?" to "should we own the code we run on?"

This guide is for CTOs and founders weighing that decision. Figures in the scenario are illustrative; prices are RemitSo's published ones.

White label and source code ownership are not better and worse versions of the same thing. They put the line between your team and the vendor in different places. With white label, the vendor runs and changes the platform and you configure it. With owned code, your team can change anything, and your team is responsible for everything it changes.

A useful way to frame it: if your roadmap is mostly new corridors, prices and partners, white label already covers it, because on RemitSo a new corridor is a setting rather than a project. If your roadmap is mostly things that do not exist yet, ownership starts to make sense.

"Source code" can mean anything from a partial export to a full platform, so pin down the scope first. RemitSo's source code covers the complete, unencrypted platform in six layers:

• Backend: the API layer, which you can host in your own data centre or private cloud, with no dependency on RemitSo after transfer.
• Database: customer, transfer and identity data stay in your infrastructure, which supports data-residency rules.
• Front end: the admin panel for onboarding, transfers, corridors, fees and compliance, plus the customer web app.
• Mobile: one full codebase for the iOS and Android apps; the real apps, not a demo build.
• Integrations: ready-made patterns for identity check providers and payment gateways, with the API for anything else.
• Docs and support: full technical and API documentation, 2 months of handover help, and 6 months of fixes and updates.

It comes as a perpetual licence with no modules held back, no renewals, no per-seat fees and no revenue share. Also included: help connecting gateways and identity providers, and guidance on moving your existing data.

Audit before you commit

The buying process has six steps: technical consultation, commercial offer, contract, live code audit, decision point and secure code transfer. The audit opens once the contract is signed, and your engineers work in the real codebase before anything is transferred. The page suggests a specialist for each part: backend (setup, repository access and API structure), admin and web app (architecture, API docs and testing), mobile apps (iOS and Android builds and testing), release pipeline (branching, automated tests and releases), and business logic (money flows, ledger and compliance in the code). The length of the audit is set in the commercial offer. At the decision point you sign off or walk away.

Ownership moves responsibility as well as control. RemitSo sets out the split plainly, and it is worth adopting the same three columns in your own board paper.

After transfer, handover help runs for 2 months as fortnightly calls with a set agenda. Critical fixes, meaning serious bugs and security issues in the delivered code, run for 6 months, and updates in that period are delivered to your private repository. After 6 months nothing is taken away; you keep the code and every update, and ongoing support can be arranged if you want it.

Note that your own changes fall outside RemitSo's fix and security cover. And the price excludes hosting, third-party fees such as gateways and identity check providers, custom development, and support beyond the included periods.

The value of owning the code is building what nobody else has. The risk is building it in a way that tangles your changes with the core, so every update becomes a merge you dread. Treat your work as modules on top of the core, and use the audit to find out exactly where they can attach.

Rather than assuming an architecture, take these questions into the audit and get answers from the code itself:

1. Where can new functionality live without editing core files? Is there a pattern for adding a module alongside the existing ones, or does every feature mean changing shared code?
2. How does a new money movement reach the ledger? If your module moves money, it must post to the same double-entry ledger as everything else. Find the path a payment or payout takes into the accounts and copy it, rather than writing to balances directly.
3. How do new integrations follow the existing patterns? The code includes patterns for identity check providers and payment gateways. A new payout partner or wallet provider should look like the existing ones, so logging, retries and error handling behave the same way.
4. How are permissions added? Every new screen and action should be grantable by role in the same way as the existing ones, not open to every admin.
5. How do compliance checks apply to new flows? A new product that bypasses screening, limits or risk rules is a regulatory problem, not a feature. Trace how an existing transfer passes through them.
6. How do releases and tests work today? Your module needs to ship through the same pipeline, with the same automated tests, as the core.

Write the answers down as your internal extension guide; it becomes the onboarding document for every engineer you hire.

You are answerable for every change to software that moves customer money. Good governance is ordinary engineering discipline, applied consistently:

• Branching. Keep the code as delivered on its own line, and your changes on another. When an update arrives during the 6-month period, you can see exactly what changed in the core and merge it deliberately.
• Testing. Put automated tests around money flows first: payments, payouts, refunds, fees, FX and the ledger entries each produces. A broken ledger entry may not be noticed until month-end.
• Review. Require a second engineer to approve every change, and a named business owner to approve any change to money flows or compliance logic. Nobody approves their own change.
• Releases. Release through a staging environment that mirrors production, on a predictable schedule, with a rollback plan written before each release rather than after it fails.
• Records. Keep a change log your compliance officer can read: what changed, why, who approved it, when it went live.

RemitSo publishes two ways to buy: $77,999 once, or $20,000 a year for 5 years, $100,000 in total. All prices are in US dollars. On the 5-year plan you can customise from year one, and the full source code is transferred after your fifth payment.

The plan costs $22,001 more over five years. In return you keep cash in the business for the first three years, and your engineers learn the code before it is yours. The single payment makes sense when you have the capital and want the code transferred immediately. The plan makes sense when that capital would otherwise fund growth, such as new corridors or prefunding. Ask your finance lead what that retained cash is worth against the $22,001.

Ownership is the wrong answer when:

• Your roadmap is configuration. If what you need is more corridors, partners, prices and rules, white label already does this.
• You have no engineering team to run it. Uptime, incident response, deployment and monitoring move to you. Without people to do that, ownership adds risk rather than control.
• You want someone else to answer for uptime. White label comes with a 99.99% uptime SLA. Once the code is yours, so is the outage.
• Your custom work is small. One or two features may be cheaper to have built on white label, where engineering is billed only for time logged.
• Nobody can staff the audit. If you cannot check the code properly, you are buying on trust. RemitSo offers audit support for teams that are short of people; use it, or wait.

All numbers below are illustrative, not drawn from any real operator.

An operator licensed in three countries runs on white label and wants two things the platform does not offer in its shape: a module for its own network of cash agents, and a portal for small business customers. Its CTO estimates both at around nine months of work for a team of four engineers, plus continuing changes as the agent network grows.

Step 1: test the decision

The roadmap is mostly new functionality, not configuration, and the work continues for years. The operator already employs engineers who run its internal systems and could take on deployment and monitoring. Ownership fits.

Step 2: audit with the modules in mind

The CTO staffs the audit with four people, one covering both the backend and the release pipeline. They also answer the extension questions: where an agent module would attach, how agent cash-in would post to the ledger, how new permissions would be added for agent supervisors, and how screening and limits would apply to agent-originated transfers.

Step 3: choose how to pay

The operator has the $77,999 but plans to open two corridors next year, which need prefunding. It chooses the 5-year plan, starts building in year one, and keeps $57,999 of licence money in the business in the first year.

Step 4: govern from the first commit

The delivered code sits on its own branch. The agent module is built alongside it, with tests around every ledger posting it creates. The compliance officer approves any change that touches screening or limits. When updates arrive, the team sees exactly what changed and merges it deliberately.

RemitSo offers the full platform as owned source code, with a buying process designed so you can check the code before you commit.

• Complete, unencrypted code: backend, admin panel, web, iOS and Android, so you can change anything your roadmap needs.
• Perpetual licence, nothing held back: no renewals, no per-seat fees and no revenue share, so your costs fall to hosting, your team and third-party services.
• Live code audit before transfer: your engineers work in the real codebase and you can walk away at the decision point, so you buy on evidence.
• Host where you choose: your own data centre or private cloud, with data kept in your infrastructure, which supports data-residency rules.
• Integration patterns and documentation: ready-made patterns for identity check providers and payment gateways, plus full technical and API documentation, so new integrations follow known shapes.
• Handover and cover: 2 months of fortnightly handover calls and 6 months of critical fixes and updates delivered to your private repository.
• Two ways to pay: $77,999 once, or $20,000 a year for 5 years with customisation from year one, so you can match the purchase to your capital plan.

Your team still takes on uptime, incident response, infrastructure, deployment, monitoring and every custom module you build. See source code pricing for the full terms, or the admin features you would be building on. For the wider trade-off, read build vs white label: the true costs.