For Banks
Your customer. Your AML. Your settlement. More merchants.
A KCB-anchored switch that lives inside your bank app. No third-party wallet between you and your customer — ever.
Pain Points
What you're up against today.
- ×A third-party wallet sitting between you and your customer
- ×Merchant acquisition that demands new identifiers your customers don't recognise
- ×Heavy ISO 20022 retrofits on a core that wasn't designed for it
- ×Settlement schemes you don't fully control
With Lipafo
A better way, today.
REST/JSON, Daraja-pattern
The same API shape your team already knows. ISO 20022 not required.
Existing Paybills & Tills
Your registered merchant list is exposed via the Bank Merchant API. No new identifiers.
You own AML, KYC & fraud
Lipafo does not screen. Your existing controls remain authoritative.
EOD position advice
At 00:00 EAT we send your bilateral net positions. Your treasury initiates RTGS by 12:00 T+1.
Frequently asked.
Is Lipafo a wallet?+
No. Lipafo is a switch and settlement notification engine. The customer experience lives inside your bank's app, not a Lipafo-branded wallet.
Who anchors settlement?+
KCB Bank Kenya anchors the pilot — hosting the interbank suspense GL. Each participating bank initiates its own RTGS from its own CBK nostro.
Is MPESA involved?+
No. Lipafo is an independent rail. Zero Safaricom or MPESA involvement in any transaction.
Do we issue new merchant numbers?+
No — Lipafo adopts your existing Paybill and Till numbers as the merchant identifiers.
What is the message protocol?+
REST/JSON in the Daraja API pattern. ISO 20022 was explicitly removed in v3.0 of the spec.
Stay close to the journey.
Notes from the Lipafo–KCB team as more banks join the rail.
Quiet emails. Real updates. Unsubscribe anytime.