Open Source Money Transfer: The Licence Traps

Midaz, one of the better-known open source ledgers, stopped being open source on 5 February 2026. There was no blog post. Commit eb432e2 swapped the Apache 2.0 licence for the Elastic License 2.0, and every tag from v3.6.0 onwards ships under it.

That is the problem with searching "open source money transfer" today. The pages that rank are a 2021 awesome-list, a product page for an ACH tool whose blog stopped in 2012, and personal budgeting apps. None of them names TigerBeetle, Formance, Midaz, Blnk, Mojaloop or Rafiki. None of them states a licence. And none of them mentions that the code is the cheap part of moving other people's money.

This guide splits the stack into layers, checks the actual LICENSE file for each project, and flags the correctness and regulatory traps a README badge will not show you.

What Is an Open Source Money Transfer Stack?

Nobody ships "a money transfer system". You assemble one from four layers that do very different jobs, and most confusion comes from comparing projects across layers.

A remittance startup needs a ledger, one or two rails and screening. A central bank building an instant payment system needs a switch. Treating Mojaloop and TigerBeetle as alternatives is like comparing Kafka with Postgres because both store bytes.

Which Open Source Payment Projects Are Really Open Source in 2026?

This is the table I could not find anywhere else. Every row comes from the project's LICENSE file as served on 11 September 2026, not from a README badge.

Three of these deserve more than a table cell.

TigerBeetle vs Formance vs Midaz vs Blnk: Which Open Source Ledger?

The ledger is the only layer where you genuinely have four credible choices, and they make very different bets.

TigerBeetle is the strict one. A transfer is a fixed 128-byte record: id, debit_account_id, credit_account_id, amount and pending_id as u128, three user_data fields at 128, 64 and 32 bits, a ledger, a code, flags and a timeout. There is no free-text metadata and no SQL. You get two-phase transfers through the pending, post_pending_transfer and void_pending_transfer flags, atomic chains through linked, and a hard limit of 8,189 events per request.

Be careful with the headline number. The docs say TigerBeetle is designed for one million transactions per second. The homepage advertises 100K to 500K TPS. Neither is a published benchmark of your workload, and I would not put the 1M figure in a capacity plan.

The stronger artefact, and the one no ranking page cites, is Jepsen's analysis published on 6 June 2025. Kyle Kingsbury tested 0.16.11 through 0.16.30, found that queries with multiple predicates often returned missing results (fixed in 0.16.17) and recorded seven crashes, including panics during upgrades. By 0.16.30 the database appeared to meet its strong serializability claim. That is more independent correctness evidence than the other three have combined.

Formance takes the opposite bet: flexibility through a small language. A Numscript fee split looks like this, from the project's own cookbook:

vars { number $amt  number $cap  portion $fee }
send [USD $amt] (
  source = @world
  destination = {
    $fee to { max [USD $cap] to @fees  remaining to @dest }
    remaining to @dest
  }
)

Capped fees, waterfalls and splits become data rather than code. The trade-off is that you are now reviewing money movement written in a DSL your auditors have never seen.

My rule of thumb: TigerBeetle when throughput and correctness dominate and you are willing to keep metadata elsewhere; Formance Ledger when posting rules change weekly; Blnk when you want inflight and scheduled transactions plus bank-file reconciliation out of the box under Apache 2.0. Midaz only if ELv2 is acceptable to your legal team, which it usually is not for a platform business.

How Do You Retry a Failed TigerBeetle Transfer?

This is the correctness trap I see teams walk into, because it breaks the idempotency pattern everyone copies from card APIs.

TigerBeetle treats the transfer id as the idempotency key. Submit the same transfer twice and the second call returns exists. Submit the same id with a different amount and you get exists_with_different_amount, one of eleven such results covering every mutable field.

The surprise is id_already_failed. If the first attempt failed with a transient error, that id is burnt. The transient results are:

• debit_account_not_found, credit_account_not_found
• pending_transfer_not_found
• exceeds_credits, exceeds_debits
• debit_account_already_closed, credit_account_already_closed

So the naive design, where the client's Idempotency-Key header is hashed straight into the transfer id, is wrong. A payer who hit insufficient funds at 09:00 and topped up at 09:05 can never complete that payment. The fix is to separate the two concepts:

request_key  ->  [attempt_1_id (failed: exceeds_debits),
                  attempt_2_id (ok)]
transfer_id = hash(request_key || attempt_number)

Store the attempt list in your API layer, return the stored outcome for true duplicates, and increment the attempt number only when the previous result was transient. Card-style idempotency, where the key replays a stored response, lives above the ledger, not inside it.

Is Hyperswitch Fully Open Source?

The core is. Hyperswitch is Rust, Apache 2.0, about 43,600 GitHub stars, and has never changed its licence. Its connectors directory holds 152 integrations, although the README claims a more conservative "120+". Nothing else open source comes close: Medusa ships exactly one payment provider in its main repository, Stripe.

The routing brain is a different matter. juspay/decision-engine, which the README describes as the control plane that picks the best gateway per transaction, is AGPL-3.0. If you modify it and expose it over a network, section 13 obliges you to offer the modified source to those users. For an in-house merchant that may never bite. For a payments company offering routing to its own customers, it is a legal review.

There is also a component you cannot inspect. config/development.toml configures a gRPC dynamic_routing_client on port 8000 with service = "dynamo". There is no public juspay/dynamo repository. Plan your deployment on the assumption that dynamic routing is either something you build or something you buy.

Hyperswitch vs building on Stripe or Adyen directly is the real comparison. Hyperswitch buys you processor independence and retry routing. It does not buy you an acquiring relationship: every connector still needs a merchant account with that processor.

Can You Run Mojaloop or Rafiki for Real Money Transfers?

Mojaloop is the most serious open source switch, and it has live deployments. Rwanda's eKash, run by RSwitch, launched on 27 February 2025. Treat other claims carefully: Tanzania's TIPS is cited as Mojaloop-based by the foundation and described elsewhere as built in-house, and Mowali, the pan-African mobile money venture, shut down in November 2022.

Two details matter for engineers. The FSPIOP API specification is CC BY-ND 4.0: implement it freely, but you may not publish a modified version of the spec. And Mojaloop's ISO 20022 mode is JSON, not XML, and uses pacs.081 and pacs.082 for quotes and pacs.091 and pacs.092 for FX quotes. Those four are candidate schemas the foundation proposed to the ISO registration authority, not registered catalogue messages. A downstream system that validates against the official catalogue will not recognise them. If you have been following the ISO 20022 migration, that is exactly the kind of mismatch that turns into a mapping layer nobody budgeted for.

Rafiki, the Interledger reference node, is blunter. Its README says it "should not be used in production by non-regulated entities". That is not a disclaimer to skim past. It is the project telling you that running it means holding customer money.

What Open Source Can't Give You in the UK

This is the gap every listicle leaves out, and it is where most of the cost sits.

• Authorisation. Holding or moving customer money in the UK needs FCA authorisation as a payment institution or e-money institution, or an arrangement with a firm that has it. No licence file changes that.
• Safeguarding. An open source ledger gives you balances. It does not give you the daily reconciliation, fixed reconciliation point and append-only records that CASS 15 now requires. Blnk's reconciliation module is a start; Formance's is paid.
• Scheme access. Faster Payments and Bacs need either direct participation or an indirect access provider. Cards need an acquirer and, for issuing, a BIN sponsor. Hyperswitch's 152 connectors are 152 commercial contracts you still have to sign.
• Sanctions data. The code for screening is free. The data you can legally screen against in a for-profit business mostly is not, as OpenSanctions shows.
• Rail formats that change under you. Moov archived its wire library after Fedwire moved to ISO 20022 on 14 July 2025; the old FAIM format is no longer accepted for live traffic. Open source format libraries track the rails only as fast as their maintainers do.

Will More Open Source Fintech Projects Relicense?

My prediction, and it is opinion: yes, and the ledger layer goes first.

The pattern in 2026 is already visible. Midaz moved to ELv2 in February. Medusa carved enterprise features out of MIT in August. Formance has run open core for years. These are venture-backed companies whose open source edition competes with their own cloud product, and ELv2-style licences exist precisely to stop a larger vendor hosting your code.

The projects least likely to follow are the ones where relicensing is structurally hard. TigerBeetle accepts contributions without a CLA, so it cannot unilaterally relicense code it does not own. Mojaloop sits under a foundation with its own governance. That does not make them better software. It makes them safer dependencies for something you plan to run for ten years.

What This Means for Teams Building Money Transfer in 2026

1. Read the LICENSE file, not the badge, and read it per module. Formance, Medusa and Hyperswitch all mix licences inside one organisation. 2. Pin exact versions and fail CI on licence change. A dependency update that swaps the LICENSE file hash should block the merge. Midaz shows the change can land in a minor version with no announcement. 3. Separate API idempotency from ledger idempotency. If you use TigerBeetle, derive transfer ids per attempt and test the exceeds_debits then top-up path explicitly. 4. Ask for correctness evidence. Jepsen exists for TigerBeetle. For any other ledger, write your own fault-injection tests before you trust it with real balances. 5. Budget for the parts you cannot download. Authorisation, safeguarding, scheme access and screening data will cost more than the engineering time you save. 6. Choose the layer before the project. If you are comparing a switch with a ledger, you have not finished the architecture.

I made the same argument about tooling in the stablecoin dev tools guide: the free part of a payments system is the code, and the expensive part is everything the code assumes someone else has already arranged. More of my work is at Tom Wang.