How to Build a Remitly-Like International Money Transfer App

What is Remitly

Remitly is a digital financial services company best known for helping individuals send money internationally. Customers can fund a transfer online or through the Remitly app, see the exchange rate, fee and estimated delivery time before confirming, and track the payment until it reaches the recipient.

Depending on the destination and corridor, recipients can receive money in a bank account, mobile wallet or debit card, collect cash from a local payout location or arrange home delivery. In many cases, the recipient does not need a Remitly account.

Remitly is a financial technology company, not a bank. It provides its services through regulated entities, local licences and banking and payout partners. The company has also expanded beyond consumer remittances with products for business payments, receiving money and other cross-border financial services.

Remitly’s key numbers

As of June 2026, the figures most often quoted are:

• 10.2 million: active customers in the three months to June 2026, up 20% year on year
• $23.5 billion: cross-border send volume in the three months to June 2026, up 27% year on year
• $495.2 million: Remitly’s revenue for the three months to June 2026, up 20% year on year
• 175+: countries and territories Remitly serves
• 5,300+: corridors in Remitly’s network
• 5.4 billion+: bank accounts and mobile wallets Remitly can pay into
• 490,000+: cash pickup locations, including retail outlets and banks

These figures measure different things and should not be combined. The active-customer count is distinct customers who completed at least one transaction in the three months to June 2026. It is not a registered-user count or an annual figure. Send volume is the principal amount customers moved, not revenue; the $495.2 million came from fees and FX spread charged on that $23.5 billion. The network figures, covering countries, corridors, reachable accounts and cash points, describe potential payout reach, not proof that every corridor carries comparable volume.

From digital remittance service to cross-border financial services platform

Founders Matt Oppenheimer, Josh Hug and Shivaas Gulati built the company around a problem Oppenheimer had experienced directly: sending money from a developed economy to family in a developing one meant agent visits, opaque exchange rates and no reliable way to know when the money had arrived. The first product replaced that with a mobile-first transfer showing the rate and fee upfront, launching with a single corridor (the United States to the Philippines) in 2012.

That single product has grown into an operating model with several connected parts: payout methods and language localised corridor by corridor; several funding and payout options per route; real-time tracking; treasury and FX capability to source and hold the currencies it pays out; and a network of banking and payout partners. More recently, Remitly has added adjacent products for business senders and repeat customers.

None of this is visible inside the app. It is the infrastructure that makes the app’s promises possible. For the same infrastructure question from the payment-acceptance side of fintech, see how to build a solution like Stripe.

Why Remitly became popular

Five factors explain Remitly’s growth.

It made sending money easier to understand

Remitly shows the exchange rate, fee and estimated delivery time before a transfer is confirmed, and its Perfect Delivery Guarantee refunds the fee automatically if delivery is late. Saved recipient details, delivery tracking and payout that does not always require a Remitly account remove much of the friction for both sides.

It localised the sender and recipient experience

Remitly matches each corridor with the payout methods that matter locally: bank deposit and mobile money in parts of Africa, GCash in the Philippines, and retail networks like OXXO and Elektra in Mexico.

Its network supported speed and reliability

Delivery speed depends on the route: direct partner integrations and instant-payment rails move faster than routes relying on intermediaries. Several partners per corridor add redundancy, so one partner’s outage does not stop the route.

Scale improved economics and risk decisions

More volume means more pricing and fraud data, and more partner leverage, a flywheel Remitly credits for its improving margins: GAAP operating margin reached 13.5% in the three months to June 2026, up from 3.5% a year earlier.

Repeat use and adjacent products broadened the relationship

Most customers send repeatedly, not as a one-off, and Remitly has used that relationship to add Remitly Business and, for a subset of US customers, Remitly One and the Global Card.

Remitly’s presence across global markets

A licence or a country listed in a footprint figure is not, by itself, evidence of popularity. It shows legal availability, not usage. Remitly’s own disclosures show senders concentrated in the United States, Canada, the United Kingdom and other European markets, while Mexico, India and the Philippines are among the largest receive markets by volume, with Mexico its single largest corridor. Adoption in most other markets is not publicly disclosed, and a broad country and corridor footprint does not mean every route carries comparable volume or offers the same payout choice.

How Remitly makes money

Remitly’s revenue comes overwhelmingly from its core money movement product: transaction fees charged to the sender, plus the spread between the interbank exchange rate and the rate offered to the customer. In the three months to June 2026, revenue was $495.2 million against $23.5 billion in send volume. That is a reminder that the principal customers send is not revenue; most of it is paid out to recipients.

Remitly does not separately disclose the exact split between fee and FX-spread revenue at this cut-off, so the table describes the mechanism rather than a percentage.

How to assess the economics of your first remittance corridor

For a new remittance product, transfer fees and FX spread are only the starting point. Estimate contribution per completed transfer after pay-in processing, payout partner charges, FX execution costs, verification and screening costs, expected fraud and chargeback losses, and variable support costs.
Compare funding and payout combinations separately: a card-funded cash-pickup transfer can have a different cost structure from a bank-funded bank deposit. Model repeat usage and customer acquisition costs alongside these transaction economics. Budget prefunding and liquidity separately: they require working capital, even though the principal placed with a partner is not itself a transaction expense.

Essential features of a cross-border money transfer app

A product like this is not a mobile screen on top of a payment API. It is closer to an end-to-end operating system for moving money, connecting the sender’s journey to regulated onboarding, transaction records, treasury, partner routing, payout and support.

• Sender onboarding and KYC. Registration, identity verification and risk tiering that decide how much a new customer can send before manual review. Too strict and you lose good customers; too loose and you absorb fraud.
• Recipient details and corridor-specific requirements. Let senders save recipients and collect the details required for each destination and payout method, such as a bank account number, mobile wallet identifier or cash-pickup information. Design the journey so the recipient can receive funds without registering in your app where the payout partner supports it. Receiving funds without an app account does not remove identification or verification requirements.
• Quote, FX, fees and limits. A live rate, spread, fee and delivery estimate shown before the sender confirms, refreshed as rates move and expiring after a set window.
• Funding methods. Bank transfer, card or wallet used to collect the sender’s money, each with its own cost, speed and failure pattern.
• Local payout methods and partner routing. Support the payout methods needed in the first receiving market: bank deposit, mobile wallet or cash pickup. For cash pickup, provide location information, collection instructions, reference numbers and payout status. Define how the system handles uncollected transfers, partner outages and refunds, with alternative routing where partner coverage permits.
• Transaction lifecycle and tracking. Status updates from creation to confirmed delivery, visible to the sender: the mechanism behind tracking and delivery-guarantee promises.
• Ledger, settlement and reconciliation. A double-entry record where every movement is written twice, as a debit and a credit, so balances stay accurate and traceable.
• Fraud, AML and sanctions controls. Screening, transaction monitoring and case review running continuously: a compliance function with people and evidence trails, not one check at signup.
• Treasury, liquidity and prefunding. Currency held with partners in advance so a payout can complete before matching inbound funds clear, an operating cost rather than a one-off task.
• Localisation, notifications, support, cancellations and refunds. Local language, delivery notifications, and the ability to cancel or refund a transfer cleanly when something goes wrong.

A first release does not need all of this at global scale. It needs all of it for one sender segment and one corridor, done correctly, before the next one is added.

How does a cross-border money transfer app work?

The flow, in outline: sender → onboarding and eligibility → corridor quote → funding → risk and compliance checks → transaction and ledger records → partner routing → recipient payout → status, settlement and reconciliation. In nine steps:

1. Create and verify the sender. Registration and identity checks establish who is sending and what they are allowed to send.
2. Capture recipient and corridor. The sender adds a recipient and the system applies that corridor’s specific rules and payout options.
3. Calculate rate, fee and delivery estimate. A quote is generated and shown before the sender commits to anything.
4. Choose funding and payout methods. The sender picks how to pay in; the recipient’s available payout methods are already corridor-specific.
5. Authorise or collect funds. The funding method is charged or debited, and the result is recorded immediately.
6. Run fraud, AML and sanctions controls. Automated checks, and manual review where a case needs it, before the transfer proceeds.
7. Record and route the transfer. The transaction is written to the ledger and sent to the selected payout partner.
8. Confirm recipient delivery. The payout partner reports completion, and the sender sees a status update.
9. Reconcile external reports, settle obligations and update status. Internal records are matched against partner reports, and any discrepancy is investigated.

The exact path changes with the send and receive jurisdiction, currency, customer and recipient type, amount, funding method, payout method, risk result, partner availability, local cut-off times, liquidity and licence scope.

Architecture of a cross-border money transfer app

What follows is a vendor-neutral logical architecture describing the responsibilities such a product has to cover, not a reconstruction of Remitly’s or any other company’s confidential design. Six layers, moving from the customer inward to the systems that keep the product running:

• Customer channels and localisation: mobile and web apps, language, notifications, and separate sender and recipient journeys.
• API and partner integration: authentication, partner connections, webhooks and duplicate-request protection, since a retried request must never send money twice.
• Transaction core and ledger: the double-entry ledger, accounts and transaction states. This is the system of record: the authoritative answer to whose money this is and what state it is in, and every other layer defers to it.
• Quote, FX, treasury and liquidity: rate sourcing, spread and fee rules, quote expiry, and prefunding (currency placed with partners in advance so a payout can complete before matching inbound funds clear).
• Pay-in and payout orchestration: funding-method handling and payout routing across banks, mobile wallets and cash-pickup networks, including automatic returns when a payout cannot complete.
• Compliance, fraud, reconciliation and operations: KYC and KYB, AML monitoring, sanctions screening, reconciliation, and the back office and support tooling a small team needs to run a product used by many.

Typical failure modes worth designing for from day one: a stale quote honoured after the market has moved, duplicate funding from a retried request, delayed bank settlement, a partner timeout mid-payout, an unavailable payout location, insufficient prefunding in a corridor, a sanctions hold that stalls a transfer, and reconciliation records that will not match.

Technical requirements for building a money transfer app

A short list of requirements is close to non-negotiable, though none prescribes a specific language or cloud provider: idempotent transaction processing so a retried request cannot duplicate a payment; an immutable audit trail; double-entry records; configurable corridors and limits; quote expiry; real-time status; partner APIs and webhooks; encryption in transit and at rest; tokenisation for card data; strict access control; sanctions and risk decisioning; reconciliation; tested backups; disaster recovery; and monitoring that alerts on business-process failures, not only server health.

Two constraints carry commercial consequences. Data residency rules in some markets require customer data to stay in-country, affecting hosting decisions before launch. PCI DSS scope applies wherever the product touches card data for funding; the usual approach is to minimise that scope by leaving raw card data with certified providers. A vendor’s own certification covers that vendor’s environment. It does not automatically extend to the customer’s entire service.

How to build an app like Remitly

The eight steps below answer the practical question of how to build an app like Remitly, or any comparable cross-border money transfer product, broadly in the order decisions actually need to be made.

Step 1: Define the customer and corridor

Choose one sender segment, one core need and one specific send-to-receive market pair before writing a specification. Define who sends, who receives, how often they transfer and the typical amount. Then validate how recipients can actually access the money: through a bank account, mobile wallet or nearby cash-pickup location. Select the initial corridor using customer demand, available payout coverage, regulatory feasibility and expected contribution per transfer. A broad, multi-corridor ambition from day one is the most common way this kind of project loses focus.

Step 2: Map the complete money flow

Define currencies, funding method, payout method, delivery promise, cancellations, refunds, settlement and reconciliation for that one corridor, including what happens when something fails partway through.

Step 3: Define the regulatory model

Identify the licensed send-side entity, receive-side obligations, safeguarding, AML programme, sanctions screening, consumer disclosures and local legal advice. This decision, more than any technical one, sets the realistic launch date.

Step 4: Design treasury, FX and liquidity

Decide quote sourcing, spread and fee rules, rate expiry, hedging where applicable, prefunding levels and corridor-level liquidity controls. An underfunded corridor stops working regardless of how good the software is.

Step 5: Select the technology approach and MVP

Compare a full custom build, several specialised vendors, and a pre-developed FinTech transaction platform configured for remittance, then scope one reliable end-to-end journey rather than a broad feature set.

Step 6: Contract and integrate partners

Cover acquiring or pay-in, banking partners, processors, KYC and sanctions-screening providers, FX and liquidity partners, and payout aggregators or direct payout partners. Partner due diligence routinely outlasts the software build and should run alongside it, not after it.

Step 7: Test the full corridor

Test the awkward cases, not the happy path: duplicate requests, insufficient funds, expired quotes, partner timeouts, payout rejection, compliance holds, reversals, refunds, chargebacks, reconciliation breaks and partner failover.

Step 8: Launch and expand carefully

Start with controlled limits and a monitored customer cohort. Use delivery performance, loss rates, support volume, reconciliation breaks and retention evidence to decide what to build next, not a fixed roadmap set before launch.

Licences and partners required for a money transfer app

A money transfer app cannot operate through software alone. The company needs a regulated entity authorised to provide payment services in the sender’s market and partners that can collect, safeguard, convert and pay out customer funds.

The first decision is whether to obtain licences directly or work through a licensed bank, payment institution or money transmitter. Direct licensing gives the company more control over its product and expansion but requires regulatory capital, compliance specialists, documented controls and ongoing reporting. A licensed-partner model can shorten the route to market, although the partner will still review the product’s money flows, compliance procedures, supported corridors and transaction limits.

Requirements differ by jurisdiction. In the United States, a money transmitter may need both federal Money Services Business registration with FinCEN and the applicable state licences. In the UK or EU, the business may require authorisation as a payment institution or electronic money institution. A licence in one jurisdiction does not automatically permit operations in another, so the regulatory model must be defined separately for every sender market.

The company must also establish which entity:

• contracts with the sender and receives the funds;
• safeguards customer money;
• performs KYC, AML and sanctions checks;
• converts currencies and manages liquidity;
• instructs the recipient payout;
• handles failed transfers, cancellations and refunds;
• reconciles transactions and submits regulatory reports.

A typical remittance product requires several partner categories. Pay-in partners, such as banks, card processors or open-banking providers, collect money from the sender. Banking and safeguarding partners hold customer funds. KYC and compliance providers support identity verification, sanctions screening and transaction monitoring. FX and liquidity providers supply the required currencies, while banks, mobile wallets, cash networks or payout aggregators deliver funds to recipients.

Using external providers does not transfer regulatory responsibility to them. The licensed entity must understand their controls, monitor performance and ensure that its internal ledger matches bank, processor and payout-partner records.

Licensing and partner onboarding frequently take longer than software implementation. Both should begin while the product is being designed. A technically complete platform still cannot launch without the required permissions, safeguarding arrangements, liquidity and signed payment-provider agreements.

Build from scratch or use a pre-built remittance platform?

The question to answer is where the product’s real differentiation will live. If it is in the ledger and transaction logic itself, building it makes sense. If it is in corridor selection, pricing or distribution (which is usually the case for a new entrant), rebuilding the accounting layer from scratch spends the budget in the wrong place.

How long does it take to build a money transfer app?

With a pre-built platform such as SDK.finance’s, the implementation timeline depends mainly on the chosen delivery model:

• SaaS: a few weeks. SDK.finance sets up the development instance, while the customer configures currencies, accounts, fees and limits, adapts the interfaces and connects the required external services. Staging and production environments follow once testing is complete.
• Source Code Licence: a few months. The process covers requirements analysis, a code audit, code transfer, infrastructure setup, customisation, integrations and end-to-end testing.

These estimates cover software implementation only. Licensing, provider onboarding, certification and regulatory approval routinely extend the commercial launch date well beyond the software timeline, so the two need to be planned in parallel, not one after the other. A platform that is technically finished while a money-transmitter licence is still pending is a common, expensive way to miss a launch date.

How much does a money transfer app development cost?

A realistic budget depends on the product’s scope and technology approach. Planning ranges for 2026, using a pre-built transaction platform rather than building from zero, look roughly like this:

• Focused MVP: $150,000–$380,000. One corridor and currency pair, customer onboarding, transfers, basic KYC/AML integration, a ledger, back office and one payment provider.
• Launch-ready product: $380,000–$750,000. Multiple integrations, stronger compliance tooling, reconciliation, branded applications, security testing and operational workflows.
• Multi-country custom platform: $750,000–$1 million or more. Several corridors, extensive custom development, card functionality, complex infrastructure and country-specific requirements.

Based on SDK.finance’s experience, these are planning ranges, not fixed prices, and they exclude financial licences, regulatory capital, prefunding, provider fees and ongoing compliance and operations, costs that are often underestimated in money transfer projects. A product approaching Remitly’s global scale, with hundreds of corridors and a worldwide payout network, would require substantially greater long-term investment. SDK.finance’s Source Code and SaaS pricing pages cover the software side in more detail.

Build a money transfer app with SDK.finance software

Building a money transfer product involves two separate challenges. The first is creating the financial software that manages customer balances, currencies, fees, transfers and transaction records. The second is securing the licences, liquidity and financial partners needed to move real money.

SDK.finance provides the software foundation for a consumer remittance solution: accounts, transaction records, configurable fees and limits, and back-office operations. The implementation then connects the pay-in and local payout providers selected for the first corridor. Bank deposits, mobile wallet payouts and cash pickup depend on those providers’ coverage, commercial agreements and integration requirements.

The capabilities most relevant to a Remitly-like product include:

• Multi-currency wallets and accounts. Maintain customer balances in different currencies and keep every balance-changing operation recorded in a ledger-based system.
• Transfer workflows. Manage internal transfers, cash-in and cash-out operations, beneficiaries, payout statuses, failures and transaction history.
• Fees, limits and exchange operations. Configure fixed or percentage-based fees, transaction limits and currency exchange rules for different products or customer groups.
• Back-office operations. Give operations, finance and support teams the tools to manage customers, investigate transactions, configure fees and limits, and monitor system activity.
• Reconciliation and reporting. Compare internal transaction records with information received from banks and payment providers and identify discrepancies.
• Customer applications. Provide configurable web, iOS and Android interfaces for individual and business users instead of building every customer channel from the beginning.
• Integration layer. Use 650+ API endpoints, webhooks and pre-developed integrations to connect banking partners, KYC providers, payment gateways, card issuers and FX services.

The platform is available through two delivery models. A hosted SaaS deployment is designed for a more standardised and faster implementation. A Source Code Licence gives the customer greater control over customisation, infrastructure and future development. The appropriate option depends on the company’s launch priorities, internal engineering resources and infrastructure requirements.

The practical advantage is that a company does not have to build its financial core from an empty codebase. It can use an existing transaction, wallet and back-office foundation while developing the partnerships and customer proposition that differentiate its product. A focused SaaS implementation typically takes 4-6 weeks, while a Source Code implementation usually takes 2-6 months, depending on customisation, integrations and the customer’s technical readiness. These estimates cover software implementation, not licensing, provider onboarding or regulatory approval.

Companies planning a multi-currency account or remittance service can discuss their product model, target corridors and integration requirements with the SDK.finance team.

Building a money transfer app: the bottom line

Remitly’s customer experience rests on a complete cross-border operating model: licensing, localisation, partner coverage, risk decisions, FX and treasury, transaction records, liquidity, payout operations, reconciliation and support. None of that comes from the app alone. Reproducing the interface without the operating model behind it produces a demo, not a working remittance app.

The realistic starting point for a comparable Remitly alternative development project is narrow: one sender segment, one corridor, one funding method, one or two payout methods, an early regulatory decision, partner contracting run in parallel with the build, and a transaction and ledger core correct from the first transfer. Corridors, products and markets are added afterwards, on evidence from the first one.