Enterprise platforms · Banking
Real-time payments integration (FPS, instant payments, QR)
We build real-time payments integration for banks and fintechs: connectivity to instant payment schemes such as Hong Kong's Faster Payment System, SEPA Instant, FedNow, Pix and UPI, and to QR payment standards, with proxy lookup, 24/7 posting, fraud checks inside the payment flow and clean reconciliation. The work sits beside your core and channels, and you own the code.
Checklist · Payments
Payment hub and ISO 20022 readiness checklist
A checklist for banks and payment firms planning a payment hub, a real-time payments connection or an ISO 20022 migration: formats, mapping, validation, routing, exceptions, reconciliation and resilience.- 01Eight areas to review before you choose or build a payment platform.
- 02The message and data points that cause rejections: addresses, identifiers and remittance data.
- 03Questions on cut-offs, liquidity and exception handling.
- 04Seven questions to put to any vendor or development partner.
Free download
Get it on screen in a few seconds.
What the system does, module by module.
- 01
Scheme connectivity
Secure connections to the instant payment scheme or its participant gateway, with certificate handling, heartbeats and automatic reconnection. - 02
Always-on processing
A processing core that runs every hour of every day, with maintenance done by rolling deployment rather than downtime windows. - 03
Proxy and alias lookup
Resolution of mobile numbers, email addresses and scheme identifiers to accounts, with registration, update and removal of the customer's own aliases. - 04
Payment lifecycle and timeouts
Sending, receiving, accepting, rejecting and returning, with exact handling of timeouts, duplicate messages and late responses so no payment is lost or doubled. - 05
Real-time posting and limits
Immediate debit or credit in the core or a stand-in ledger, with per-customer, per-channel and per-scheme limits checked in the flow. - 06
Fraud and name checks
Risk scoring before release and, where the scheme or law requires it, verification of payee, with the result shown to the customer before they confirm. - 07
Request to pay
Payer-approved collection requests and their status, for billers, merchants and marketplaces. - 08
QR payments
Generation and scanning of static and dynamic QR codes following the market's QR specification, for in-store, bill and person-to-person payments. - 09
Liquidity and settlement
Tracking of the settlement position with the scheme, alerts when funding runs low and reconciliation against settlement files.
Reference architecture.
Standards and interfaces
What we design against.
- Scheme rulebooks and interface specifications
- Each scheme (Faster Payment System in Hong Kong, SEPA Instant Credit Transfer, FedNow, Pix, UPI and others) defines message sets, timeouts and rules that the integration implements exactly.
- ISO 20022
- The message basis for most instant schemes, with a scheme-specific profile on top.
- QR code specifications
- The local QR payment standard, such as EMVCo's merchant-presented mode and the common QR specifications issued by regulators.
- EU Instant Payments Regulation
- Verification of payee and availability obligations for payment service providers in the euro area, designed into the flow where they apply.
- Strong customer authentication
- Step-up rules and risk-based exemptions for payment initiation in mobile and online channels.
- OpenAPI
- Contracts between channels, the real-time layer and the core.
Data model
The core entities.
- Instant payment
- Parties, amount, alias or account, scheme reference, status and each message exchanged with the scheme.
- Alias registration
- Alias type and value, account link, registration state and history.
- Request to pay
- Requester, payer, amount, expiry, status and the payment it produced.
- QR payload
- Merchant or payee data, amount rules, expiry and scan outcomes.
- Limit and risk decision
- Limit applied, score, rules fired, decision and any customer step-up.
- Settlement position
- Net position with the scheme, funding movements and the files they reconcile to.
- Reconciliation item
- Payment, settlement entry, difference and resolution.
When custom development is the right call.
Controls designed in, not added later.
Strong authentication
Step-up for risky payments, device binding and limits that adjust with behaviour.Secure scheme connectivity
Mutual TLS, certificate rotation and keys held in hardware security modules.Exactly-once effects
Unique references and de-duplication, so a timeout or retry never moves money twice.Fraud controls in the flow
Scoring before release, velocity and mule-account signals and a path for a customer to confirm or cancel.Resilience
Redundant gateways, health checks, replay of unacknowledged messages and tested recovery.
From discovery to a system you run.
- 01
Scheme and flow selection
We confirm which schemes, payment types and customer journeys come first, and read the rulebooks and test plans with your payments team. - 02
Architecture and stand-in design
The always-on design, the posting model and the interfaces to the core and fraud systems are agreed. - 03
Build and scheme certification
The integration is built and run through the scheme's test and certification process. - 04
Pilot with a customer group
A limited customer group sends and receives real payments with tight limits while monitoring is tuned. - 05
Scale and extend
Limits are raised, QR and request to pay are added, and further schemes follow on the same layer.
Relevant work
Where to see our work.
Common questions.
- Can the core keep posting when it is down for maintenance?
- If the core cannot run always-on, we add a stand-in ledger that posts payments in real time and settles to the core when it returns, with a reconciliation that proves they agree.
- How do you avoid duplicate payments on a timeout?
- Every payment has a unique reference and a state machine. A timeout triggers a status query to the scheme rather than a resend, and the posting step ignores a reference it has already processed.
- Do you support more than one scheme on the same layer?
- Yes. Each scheme is a connector and a rules profile behind the same payment lifecycle, alias and limit components.
- Where does fraud screening happen?
- Inside the payment flow, before the payment is released, using your fraud engine or one we build. The decision, the score and the rules that fired are stored with the payment.
- Who owns the code and the data?
- You do. The code, the data and any models stay yours.