Integrations separated from modules
Modules connect to the bus, which handles exchange with the core banking system. Core changes are checked for compatibility with the connectors.
An integration layer for banks in Uzbekistan: connecting mobile banking, loan origination, KYC and CRM to the existing core banking system, processing and government services.
The state and the regulator connect to banks directly
Kazakhstan. Connections come from above: interbank mobile payments and the NBK unified QR, the Smart Bridge government platform and, from 2027, “data marts” on each bank’s own infrastructure — the regulator will read bank data through an interface rather than from exports. Uzbekistan. Under the Central Bank strategy, Open Banking is planned for 2028–2029, but banks already have to integrate the unified QR, instant payments and the digital ID card with an e-signature — an integration layer is needed before open banking.
New products connect to the existing core system through an integration layer
The bus separates integrations from product modules. Connectors, queues and retries, logging and monitoring bring together exchanges with the core system and external systems.
Modules connect to the bus, which handles exchange with the core banking system. Core changes are checked for compatibility with the connectors.
Ready-made connectors reduce repeated integration development. Time to launch depends on the core banking system, external systems and product scope.
Logging, monitoring, queues and retries bring control of exchanges via the bus into one place. Errors and response times are available for analysis.
File exchange, database integrations, API wrappers: customers, accounts, postings and limits, within the available interfaces.
Card issuance and blocking, authorizations, limits and transaction history for product modules.
Transfers, QR payments, utility and telecom payments via national payment systems.
Exchange with tax and government registries, verification of personal data and identity for account opening and loan applications.
Exchange of regulatory reports, incident notifications and antifraud data; scope is agreed for each bank.
Partner APIs, customer consents, limits and access keys: the foundation for open banking.
Asynchronous messaging, retries on failure and format conversion. Load parameters are tested against the core banking system.
Request log, response times, errors and alerts. SLA is agreed for connectors.
Channel encryption, roles, module and partner keys, access audit.
Audit of the core banking system, processing, data exchange and bottlenecks; choice of the first module.
Deployment, connection of the first systems, logging and monitoring setup.
Testing the first module: load, response time, error and incident handling.
Connecting the remaining modules and partners; handover of connectors and documentation to the bank.
Most integration work is done in the bus and modules. Whether the core banking system needs changes, and how the switchover is sequenced, is determined during the audit.
The bus and connectors run in the bank’s infrastructure; the code and documentation belong to the bank. Price and timeline are set in the contract.
Infrastructure, deployment and 24/7 monitoring by Rocket Tech. Communication channels and security requirements are agreed with the bank.
New connectors, regulatory updates and SLA-based support, by subscription or by the bank’s own team.
We build the integration team, launch the processes and hand over to the bank once the agreed metrics are reached. How it works
“In Uzbekistan, no one is ready to replace the core banking system, and often there is no need. The bus sits between the core and new products, and an interface audit shows what can be connected without changes to the core.”
Oleg SolabayevCTO, Head of Ready Bank products



The bus uses the available interfaces of the core banking system. Whether it can connect without modifications is determined during the audit; replacing the core is not a required step.
Core banking, processing, payment systems, government services, biometrics, the central bank and partner APIs. A connector is developed for any new system.
No. Third-party services and the bank’s own solutions can be connected after their interfaces and data exchange requirements are reviewed.
Encryption, roles, keys and access audit. Requirements of the Central Bank of Uzbekistan and the bank are verified during design and implementation.
Queues manage request processing but do not remove the limits of the core banking system. Acceptable load, response time and SLA are tested during implementation.
After the audit, the set of connectors and the plan for connecting the first module are defined. The timeline is fixed in the contract.
Your request goes to our business development team: we will get in touch, work out what needs to go live at your bank and propose a solution.
Thank you, your request has been sent
A business development manager will contact you using the details you provided.