Building a virtual account system with direct NIBSS integration
TL;DR
I built a virtual account system with a direct NIBSS integration — connecting straight to the interbank rails rather than going through an aggregator. Each customer gets a dedicated account number that funds a shared settlement account, inbound payments are attributed and reconciled in real time, and the system processes a transaction in an average of about 3 seconds.
The problem
Collecting money reliably is one of the hardest parts of fintech. If every customer pays into one shared account, you inherit a reconciliation nightmare: which inbound transfer belongs to whom? Virtual accounts solve this by giving each customer their own dedicated bank account number that routes into a single underlying settlement account — so an inbound payment can be attributed automatically. The engineering challenge is making that provisioning, attribution, and settlement fast and dependable while talking to national payment rails.
Constraints
Payments are unforgiving: money movement must be correct, attributable, and idempotent under retries and duplicate notifications, and it has to feel real-time to the payer. Going directly to NIBSS — rather than through an aggregator — meant owning more of the integration surface: the connection, the reliability characteristics, and the reconciliation, with no middle layer to absorb faults. The bar was to keep the end-to-end path both correct and fast.
The approach
1. Dedicated virtual account provisioning. The system issues each customer a unique virtual account number mapped to a single settlement account, so any inbound transfer carries enough context to be attributed to the right customer without manual matching.
2. Direct NIBSS integration. Connecting directly to the interbank rails removes a hop from the path. That means fewer moving parts between the payer and confirmation, more control over reliability and reconciliation, and less latency than routing through an intermediary — which is part of how the system holds an average processing time near three seconds.
3. Real-time attribution and reconciliation. Inbound events are matched to the owning virtual account and settled promptly, with the transaction pipeline built to be safe under retries and duplicate notifications so a repeated event never double-credits a customer.
4. Built on a Java/Spring Boot stack. Java and Spring Boot for the services, PostgreSQL for durable transaction records, Redis for fast lookups and coordination, and Kafka to move events through the pipeline asynchronously without blocking the confirmation path.
Outcome
The system provisions dedicated virtual accounts, collects and attributes inbound payments in real time over a direct NIBSS integration, and processes transactions at an average of roughly three seconds — turning what is usually a manual, error-prone collections-and-reconciliation problem into an automated, dependable flow.
Skills this demonstrates
Payment-systems engineering, direct integration with national payment rails (NIBSS), real-time collections and reconciliation design, latency-conscious backend engineering, and building money-movement pipelines that stay correct under retries and duplication.