Rafiki
Digital PaymentsRafiki is an open-source gateway that lets a licensed financial institution connect to the Interledger network and send secure, atomic transfers using the Interledger Protocol and Open Payments APIs. Stewarded by the Interledger Foundation, it is a minimal payments building block by design: it does clearing and routing, and deliberately holds no account or ledger data of its own.
- DPG Profile: https://www.digitalpublicgoods.net/r/rafiki
- Website: https://rafiki.dev
- Source code: https://github.com/interledger/rafiki
All DPGs in the DPGs for DPI Collection are assessed by the DPGA Secretariat against the DPGs for DPI criteria v2.0. Assessments use publicly available documentation and link to their evidence below. Assessed September 2026.
17 of 18 checks met
1 partially met
Layer 1
Recognised DPG
Layer 2
DPI Relevance
Layer 3
DPI Architecture Alignment
Layer 1 Recognised Digital Public Good
Listed in the DPG Registry.
Layer 2 DPI Relevance
Does it provide a foundational DPI function, reusable across sectors, at population scale?
Core function is cross-network payment clearing and settlement for licensed Account Servicing Entities, placing it in the Digital Payments domain. The rail is purpose-neutral — the same infrastructure carries remittances, merchant payments, government disbursements and P2P transfers — and it is built for institutions and national switches rather than a single project, though adoption is still early with AMUCSS in Mexico and an in-progress Mifos integration.
- Overview: https://rafiki.dev/overview/overview/
- Account Servicing Entity concept: https://rafiki.dev/overview/concepts/account-servicing-entity/
Layer 3 DPI Architecture Alignment
How the solution's architecture reflects the principles that distinguish DPI from conventional digitisation.
A · Interoperability
3/3Can other systems connect without modifying the core, using documented open standards?
Three published API surfaces: the Open Payments REST API, an open specification any client can implement without coordinating with the maintainers; a GraphQL Admin API; and the ILPv4 connector for peering. Standards adoption covers ILPv4, Open Payments, GNAP, Ed25519 HTTP Message Signatures, TLS 1.3 and OpenTelemetry, with JSON exchanged against published specifications.
- GraphQL Admin API: https://rafiki.dev/apis/graphql/backend/
- Overview & standards: https://rafiki.dev/overview/overview/
B · Minimalist & Reusable Design
3/3Is it a modular building block that does one thing well, rather than a monolithic platform?
Backend, auth and admin frontend run as three independently deployable, horizontally scalable services over PostgreSQL, Redis and TigerBeetle. The separation between infrastructure and application is unusually clean: the deploying institution's ledger and account database stay authoritative and Rafiki holds no source-of-truth data, and deployment is configured through Docker Compose or Helm rather than by forking.
- Architecture: https://rafiki.dev/resources/architecture/
- Helm & Kubernetes deployment: https://rafiki.dev/integration/deployment/helm-k8s/
- Account Servicing Entity concept: https://rafiki.dev/overview/concepts/account-servicing-entity/
C · Ecosystem Enablement
3/3Can other public and private actors build on top of it?
Because integration happens through the Open Payments specification rather than a Rafiki-specific API, third parties can build wallets, clients and merchant integrations independently, supported by a local playground with mock institutions, autopeering and a testnet. External adoption is documented at AMUCSS in Mexico and through the Mifos Initiative's integration of Interledger into its own digital public goods; Apache-2.0 licensing under Interledger Foundation stewardship rules out vendor lock-in.
- Local playground: https://rafiki.dev/integration/deployment/docker-compose/
- Mifos ILP integration report: https://community.interledger.org/dhiggins/mifos-initiative-ilp-for-digital-public-infrastructure-ilf-grant-final-report-20l6
- Source code (Apache-2.0): https://github.com/interledger/rafiki/blob/main/LICENSE
D · Federation Readiness
2/3Can it run in distributed or federated deployments suited to national infrastructure?
Federation is the architecture, not a feature: every institution runs its own instance and peers bilaterally over Interledger, with no central instance, authority or shared database. Every database is supplied and operated by the deploying institution, so data never touches Foundation-hosted infrastructure. All three services scale horizontally and the Kubernetes guide recommends multiple replicas, but there is no worked high-availability reference architecture or guidance on clustering the accounting store.
- Architecture: https://rafiki.dev/resources/architecture/
- Helm & Kubernetes deployment: https://rafiki.dev/integration/deployment/helm-k8s/
E · Security & Privacy at Scale
3/3Does it meet the security and privacy bar for population-scale infrastructure?
Security is infrastructure-grade: TLS with optional mutual TLS, end-to-end AES-256-GCM encryption of payment data so intermediaries cannot read it, Ed25519 request signatures, per-tenant HMAC on admin calls, and role-based access control. Independent security audits are commissioned annually with summaries published after remediation, vulnerability scanning runs in CI, and privacy is designed in — no personal data is required for the software to function, consent is itemised and revocable, and defaults keep identifiers private.
- Security profile: https://interledger.org/policy-and-advocacy/security-profile-interledger-open-source-technologies
- Security audit summary: https://interledger.org/developers/blog/rafikis-first-security-audit/
- Privacy & consent design: https://rafiki.dev/overview/concepts/account-servicing-entity/
Criteria: DPGs for DPI Collection criteria v2.0 · Co-stewarded by CDPI, Co-Develop and the DPGA Secretariat.
Spot something out of date? Contact the DPGA
