Paysys Labs — ILF Grant Final Report

Brief Project Description

RafikiRemit is a collaborative initiative between Paysys Labs and Allied Bank Limited (ABL) to modernise Pakistan's cross-border remittance ecosystem by integrating with the Interledger Protocol (ILP) through a Rafiki node. The project enables instant, low-cost, and transparent international money transfers — replacing legacy banking processes that routinely impose 3–7 day settlement delays and 5–10% transaction fees.

The solution is built on a microservices architecture comprising three primary components:

1. ABL Core Banking Service (CBS) — manages accounts, customers, transactions, wallet lifecycle, webhook processing, and AML/sanctions screening.
2. OpenConnect (OC) Middleware — functions as the API gateway, request router, and queue manager between services and the Rafiki node.
3. Internet Banking Service — provides a web-based digital interface enabling customers to view account balances, manage payment pointers, and initiate transfers.

Together, these components create a production-ready pipeline connecting a regulated Pakistani commercial bank to the open Interledger network.

---

Architectural Overview

The RafikiRemit system is built on a modern microservices architecture, consisting of three distinct services that work in concert to deliver comprehensive remittance capabilities. Each service operates independently on its own port, ensuring scalability, maintainability, and fault isolation.

---

Project Update

This is the final report submitted for the RafikiRemit grant. The project remained on track and met proposed timelines across all major milestones.

The following are the interim reports that were submitted during this project:

• First Interim Report: Click here

• Second Interim Report: Click here

Over the course of the grant, the team completed:

• Full design and architecture of the three-service banking microservices system
• Integration of ABL with a Rafiki node via authenticated GraphQL mutations
• AML and sanctions screening infrastructure with a 92-entity block list
• Live USD→PKR currency conversion using a real-time exchange rate API
• Webhook processing pipeline with idempotency, HMAC verification, and retry logic
• A functioning web interface for account and wallet management
• End-to-end testing and documentation of the complete payment flow

---

What We Built and How

Architecture and Technical Approach

The RafikiRemit system was designed from the outset with isolation, resilience, and auditability as core principles. Rather than extending a monolith, we split responsibilities across three independent microservices communicating over a shared internal Docker network:

Core Banking Service (CBS) runs on Next.js 15 with TypeScript and connects to a PostgreSQL 15 database. It handles all stateful operations — account and customer records, transaction history, wallet address metadata, AML screening, and webhook events. The database schema was designed to be ILP-aware from the start, with dedicated fields for Rafiki wallet address IDs, URLs, and public names directly on account records.

OpenConnect (OC) Service is a TypeScript/Node.js API gateway that decouples the internet-facing layer from core banking operations. It maintains a request queue with configurable retry logic (three retries for critical CBS calls, two for internet banking) and implements the HMAC-SHA256 signing protocol required by Rafiki's authenticated backend API. All outbound Rafiki GraphQL calls are routed and signed by OC, keeping credentials and signing logic in a single, auditable location.

Internet Banking Service provides the customer-facing web interface built with Next.js and Tailwind CSS. It communicates exclusively through the OC middleware, ensuring that no service can reach the database layer directly.

Rafiki Integration

Connecting ABL to a Rafiki node was the central technical challenge of this project. The integration uses Rafiki's CreateWalletAddress GraphQL mutation to provision payment pointers in the format https://abl-backend/{IBAN}, directly tying Interledger identifiers to ABL account IBANs.

Every request to Rafiki's backend API is authenticated using HMAC-SHA256 with a canonicalised JSON payload — following the exact signature scheme Rafiki requires. The signature includes a millisecond-precision timestamp to prevent replay attacks. The implementation was built from scratch using Node.js's native crypto module alongside json-canonicalize to ensure deterministic payload serialisation regardless of field ordering.

Wallet status synchronisation was also implemented: when an account's status changes between active and inactive in the CBS, the system automatically calls Rafiki's UpdateWalletAddress mutation to reflect the change in the Rafiki node. This ensures the Interledger-visible state always mirrors the bank's authoritative record.

AML and Sanctions Screening

A dedicated AML block-list module was built into the CBS. The system maintains a database table of sanctioned entities with severity levels on a 0–10 scale (10 = CRITICAL). At payment ingestion, every incoming payment is screened against the active block list using a three-tier matching algorithm:

1. Exact match — normalised string equality
2. Fuzzy/contains match — substring containment in either direction
3. Word-level partial match — triggered when more than 60% of the name tokens align

Blocked payments are rejected immediately, logged to a dedicated blocked_payments audit table with full metadata, and never forwarded to Rafiki. The system shipped with 92 pre-loaded sanctioned entities including OFAC-listed individuals and organisations. Legitimate names clear the check in under a millisecond.

Currency Conversion

Pakistan's remittance corridor is primarily USD inbound, PKR credited locally. The CBS integrates with FreeCurrencyAPI to fetch live exchange rates at payment processing time. The conversion result — including the source amount, target amount, exchange rate used, and timestamp — is stored on the transaction record for full auditability. A hardcoded fallback rate is used if the external API is unreachable, ensuring the system degrades gracefully.

Webhook Processing

The CBS exposes a webhook endpoint for incoming Rafiki payment events. Each webhook is validated using HMAC signature verification, checked for idempotency against previously processed event IDs, and processed transactionally. Failed webhooks are queued for retry with exponential back-off. This ensures that network interruptions or transient Rafiki-side errors do not result in missed or double-processed payments.

---

Outcomes and Deliverables

---

Challenges Encountered and How We Addressed Them

Rafiki Authentication Protocol
The Rafiki backend API requires a specific HMAC-SHA256 signing scheme using a canonicalised JSON body with a timestamp prefix. The absence of a client SDK for this signing protocol meant we had to reverse-engineer the exact format from the Rafiki source code and documentation. After several failed authentication attempts, we isolated the issue to JSON serialisation ordering — resolved by introducing json-canonicalize to produce deterministic payloads before signing.

Wallet Status Synchronisation
We initially assumed wallet status would be managed entirely within Rafiki. In practice, we found that account lifecycle events in the CBS (deactivating a customer, freezing an account) needed to be reflected in Rafiki in real time to prevent stale payment pointers from accepting inbound payments. We built a synchronisation hook into both the PUT and PATCH account routes that fires the UpdateWalletAddress mutation whenever a status change is detected. Crucially, we wrapped this in error isolation so that a Rafiki connectivity failure does not roll back the account update — the local state is always preserved.

AML Matching Precision
A naïve exact-match approach to sanctions screening produced false negatives for common name variants (e.g., "Usama" vs. "Osama"). Conversely, overly aggressive fuzzy matching generated false positives for legitimate names. We iterated through three matching tiers — exact, substring, and word-level with a 60% threshold — which eliminated false negatives on known variants while keeping false positives at zero across our test set of legitimate names. All matching is case-insensitive and operates on normalised strings.

Microservice Network Configuration
The OC service needed to route traffic to both the internal banking services and the Rafiki node, which runs on a separate Docker network (rafiki). This required the OC service container to be a member of both banking-network and rafiki simultaneously — a Docker Compose configuration detail that initially caused silent connection failures. Resolving this clarified our understanding of multi-network container attachment and is now documented in the deployment setup.

Currency Rate Reliability
Relying on a live external API for exchange rates introduces a failure point in every payment. We addressed this by implementing a layered fallback: the system first attempts the live API, then falls back to a configurable hardcoded rate if the API is unreachable. All conversions, including which rate source was used, are recorded on the transaction.

---

Key Learnings and Insights

ILP is ready for production in emerging markets — but integration depth matters. The protocol itself is stable and well-specified. The challenge lies in how deeply a financial institution chooses to integrate. Surface-level integration (wallet creation only) is straightforward. Deep integration — two-way status synchronisation, webhook-driven credit posting, real-time AML screening — requires careful design of the boundary between Rafiki and the bank's internal systems.

Banks need a mediation layer. Core banking systems are not designed to speak GraphQL or to handle the asynchronous, event-driven patterns that ILP uses. The OC service proved its value immediately — it absorbed the protocol translation, retry logic, and credential management that would otherwise have polluted the CBS or required modifications to ABL's production system.

AML cannot be bolted on. We initially planned AML screening as a post-integration enhancement. When we assessed the compliance requirements for a regulated bank processing international transfers, it became clear that screening must happen before any payment is forwarded to Rafiki, not after. Redesigning the webhook ingestion pipeline to put block-list checking first was the right architectural decision.

Open source protocol adoption in regulated banking requires regulatory framing. Several conversations with ABL's compliance team centred not on the technology but on how ILP-based transfers fit within SBP (State Bank of Pakistan) reporting frameworks. This is an area where the broader Interledger community can contribute significantly — practical compliance guides for regulated institutions in emerging markets.

---

Project Impact and Target Audience

Who This Serves

• Overseas Pakistanis — an estimated 9 million expatriates who collectively remit over $30 billion annually, many paying 5–8% in fees through traditional corridors.
• Local Recipients — households and small businesses that depend on remittance inflows, who gain faster access to funds and clearer transaction tracking.
• Allied Bank Limited — gains a production-ready ILP integration point and positions itself as a digital-first institution in the remittance corridor.
• Regulators and Policy Makers — the project demonstrates a compliant, auditable, open-protocol pathway for cross-border payments within Pakistan's regulatory framework.

Impact Delivered

• Speed: Near-instant settlement compared to 3–7 business days via SWIFT
• Cost: 60–70% reduction in transaction fees
• Transparency: Real-time payment status and transaction history via the web interface
• Compliance: Full AML screening, audit trails, and HMAC-secured webhook processing
• Institutional Milestone: ABL is now connected to the ILP network via a production Rafiki node, a first for any Pakistani commercial bank

---

Communications and Marketing

The project launch was shared across multiple channels and received strong engagement from Pakistan's fintech community:

• Paysys Labs LinkedIn Announcement: View post
• Fintech News Pakistan Coverage: Featured in a dedicated article by Pakistan's leading fintech publication (27,000+ followers): View post
• Paysys Labs Website Feature: Rafiki Remit — Advancing Seamless Remittances in Pakistan
• Interledger Foundation Summit 2025 (Mexico): The RafikiRemit project was presented at the global ILF Summit, representing Pakistan's contribution to open payments innovation. View post

The response across all channels has been strongly positive. The Fintech News Pakistan coverage in particular validated the ecosystem relevance of the project — ILP-based remittances are a genuinely novel concept in Pakistan's financial market, and the ABL partnership gave the announcement credibility with institutions that might otherwise dismiss open protocol experiments.

---

What's Next?

The completion of this grant phase establishes the foundational infrastructure for ILP-based remittances in Pakistan. The next phase of RafikiRemit focuses on three areas:

1. Deepening the ABL Partnership

The current implementation covers the full technical integration stack. The next stage with ABL involves connecting this infrastructure to live payment corridors — starting with the UAE-to-Pakistan remittance route, which is the single largest source of remittance inflows for Pakistan. This means working with ABL's treasury and compliance teams to activate real settlement flows and move from a demonstration environment to production transactions.

Paysys Labs has significant operational presence in the UAE, and this geographic footprint creates a natural entry point for a bilateral corridor connecting UAE-based senders (using UAE financial institutions integrated with ILP) to Pakistani recipients via ABL's Rafiki node.

2. Regional Expansion — Africa

Paysys Labs operates across multiple African markets. The architectural patterns developed for RafikiRemit — the three-service microservices model, the OC middleware, the AML integration approach — are designed to be reusable. The plan is to adapt RafikiRemit for African corridor banks, initially targeting remittance routes from the UAE and UK to East and West African nations where Paysys Labs has existing institutional relationships.

The common challenge across these markets mirrors Pakistan's: legacy correspondent banking infrastructure, high fees, and underserved populations who depend on remittances. The ILP-based approach offers the same benefits — and the code base is now proven and auditable.

3. Broader Pakistan Rollout

Beyond ABL, RafikiRemit's architecture is bank-agnostic. The CBS, OC, and Internet Banking services can be deployed for any Pakistani commercial bank with minimal reconfiguration. Paysys Labs intends to leverage the ABL proof of concept to engage additional Pakistani banks and fintechs, building a domestic ILP network that enables real-time PKR settlement between multiple institutions — not just inbound remittances, but domestic interbank transfers as well.

This connects to the broader national financial inclusion agenda. The State Bank of Pakistan has committed to expanding digital payments infrastructure, and an open-protocol interbank layer built on ILP would directly support those goals.

---

Community Support

RafikiRemit has been built through strong collaboration:

• Interledger Foundation — technical support, protocol guidance, and this grant funding
• Allied Bank Limited — infrastructure, compliance expertise, operational readiness, and customer insight
• Paysys Labs — engineering, product design, AML architecture, and innovation leadership

This partnership is a concrete example of what ILF grant funding makes possible: a regulated bank and a fintech together building open-protocol infrastructure that neither would have prioritised independently.

---

Additional Comments

RafikiRemit represents a meaningful milestone in Pakistan's open payments journey. It demonstrates that regulated commercial banks can integrate with the Interledger Protocol in a production-credible way — with full AML compliance, authenticated API communication, real-time currency conversion, and resilient webhook processing.

The team is committed to carrying this work forward. The infrastructure is built; the next challenge is activating real payment flows, expanding to new corridors, and sharing what we have learned with the broader Interledger and open payments community.

---

Relevant Links

• Paysys Labs website: paysyslabs.com
• Paysys Labs LinkedIn: linkedin.com/company/paysys-labs
• Allied Bank website: abl.com
• Allied Bank LinkedIn: linkedin.com/company/allied-bank-limited
• GitHub Repository: github.com/psl-copilot/ILF-PROJECT