Workplace-Banking System Integrations: Finacle, IPRS, CRB, KRA and More

The integrations behind workplace-banking lending — Finacle core banking, IPRS, CRB, KRA, Comply Advantage, IPPD, DMS and RTGS — and the adapter pattern, retry and circuit-breaker resilience that hold them together.

A workplace-banking lending platform is only as good as the systems it talks to. An unsecured check-off loan in the Kenyan market touches identity registries, credit bureaux, the tax authority, sanctions and PEP screening providers, the government payroll, the core banking system and the inter-bank settlement rails — often within the same application. The Creodata Workplace Banking (WPB) platform treats those connections as a first-class concern rather than an afterthought: every external system is reached through a consistent integration layer built on the adapter pattern, with retry, circuit-breaking and caching applied uniformly. This article walks through each integration, what it does at which point in the loan journey, which microservice owns it, and how the resilience pattern keeps origination moving even when a downstream provider has a bad day. For where these pieces sit in the wider end-to-end flow, see the complete guide to workplace banking.

The external systems and what each one does

WPB orchestrates a check-off loan from pre-sale calculation through disbursement, and at each gate it draws on a specific external service. These are not bolt-ons; they are the data and execution backbone of origination.

• Finacle (core banking) — the system of record for customer and account data and for the financial execution of the loan. WPB uses it to create a CIF and transactional account for new-to-bank customers, mark limits, book the loan and disburse, and to verify salary credits for existing customers. The end-to-end mechanics are covered in loan booking and disbursement to core banking.
• IPRS — national ID and passport verification, with automatic population of applicant bio-data so the application is not re-keyed by hand.
• CRB (Credit Reference Bureau) — credit history: performing and non-performing accounts, and arrears. This feeds the credit-analysis stage and the business-rules engine's CRB checks.
• KRA — verification of the tax PIN supplied by the applicant.
• Comply Advantage — AML, sanctions and PEP screening, supporting the compliance stage's politically-exposed-person check and broader financial-crime due diligence.
• IPPD — government payroll deduction verification and booking. For government ministries, the Scheme Loan Administrator generates the deduction data delivered to IPPD, which confirms capacity and books the check-off deduction.
• DMS — document workflow, and the routing and approval channel for RTGS/TT transfers, including loan-takeover settlements.
• RTGS — inter-bank transfers, used to settle buy-offs to another bank.
• SMS and email gateways — customer OTP delivery, the loan and account-opening terms-and-conditions link, and workflow notifications to staff.

How these checks are sequenced and what the reviewer sees is described in compliance checks in loan origination.

System to purpose to owning service

The integration layer is deliberately distributed across the platform's microservices so that each service owns the external calls relevant to its stage of the workflow. The table below maps each system to its purpose and the service that owns the adapter.

The Compliance service concentrates the verification and screening calls — IPRS, CRB, KRA and Comply Advantage — because those results all converge at the compliance and credit-analysis stages, where reviewers work from a split screen showing the application beside every search result. The Disbursement service owns the systems that move money or commit a financial instruction: Finacle, DMS and RTGS, plus the IPPD payroll booking for government schemes. EmployerScheme governs the scheme parameters that shape which checks apply, and EmailNotification owns the SMS and email channels.

The resilience pattern: adapters, Polly and caching

Every external integration is implemented behind the adapter pattern. Rather than scattering provider-specific calls through business logic, each system sits behind an interface, and the concrete adapter handles the protocol, authentication and payload shaping for that provider. This is what makes the platform portable and testable, and it is where the resilience policies are applied consistently.

Each adapter is wrapped with Polly resilience policies:

• Retry — three attempts with exponential backoff, so a transient network blip or a momentary provider hiccup is absorbed without failing the user's action.
• Circuit breaker — after five consecutive failures the circuit opens for a 30-second break, giving a struggling downstream service room to recover instead of being hammered, and failing fast rather than holding the workflow hostage.

On top of that, compliance results are cached for 24 hours. When IPRS, CRB, KRA or Comply Advantage has already returned a result for an applicant within the day, the platform reuses it rather than re-querying. That cuts repeated calls to rate-limited or chargeable external services, reduces latency for the reviewer, and means a brief outage at one provider does not necessarily stall an application that has already been screened. The deterministic business-rules engine then evaluates those results — minimum take-home, retirement-age and contract-maturity rules, debt-to-income, CRB rules and the rest — without depending on any machine-learning model.

Taken together, the adapter boundary plus Polly plus the 24-hour cache mean the loan workflow degrades gracefully. A single provider being slow or temporarily down is contained at its adapter; it does not cascade into the rest of origination.

How integrations map to stages

The integrations are not invoked all at once. They light up as the application advances through the 13-stage workflow:

1. Pre-sale and application capture — IPRS verifies the national ID or passport and auto-populates bio-data, so the Direct Sales Executive is not transcribing details by hand. The SMS gateway later delivers the OTP and the link to the loan and account-opening terms once documents are uploaded.
2. Document verification and data capture — checklist-driven documents are handled through the Document service, with DMS supporting document workflow.
3. Compliance and credit analysis — CRB returns credit history, KRA confirms the tax PIN, and Comply Advantage screens for sanctions and PEP exposure. These cached results sit alongside the application on the reviewer's split screen and feed the business-rules engine. The deeper treatment of this stage is in compliance checks in loan origination.
4. Check-off booking and loan booking — for government ministries, IPPD verifies deduction capacity and books the deduction; Finacle creates the CIF and account where needed, marks the limit and books the loan.
5. Disbursement and post-disbursement — Finacle executes full, partial or final disbursement; RTGS routed through DMS settles buy-offs to another bank, while SACCO settlements credit a branch suspense account with a bankers cheque issued to the branch. Throughout, the EmailNotification service issues the appropriate emails and SMS on each workflow event.

Because new-to-bank account opening runs in parallel with the loan workflow, the Finacle CIF and account-creation calls overlap with the credit decision rather than blocking it — the account-opening handoff is the same one covered by the business account opening platform.

Deployment portability: same logic, two backends

A defining property of the integration layer is that the platform runs the same business logic whether it is deployed to a bank's on-premises Kubernetes cluster or to Microsoft Azure, where WPB is available as a transactable Azure Marketplace managed application that a bank deploys into its own subscription. Feature parity is maintained across both.

The infrastructure backends behind the integrations switch by environment variable, resolved through interface-based dependency injection:

The external lending integrations — Finacle, IPRS, CRB, KRA, Comply Advantage, IPPD, DMS, RTGS and the SMS/email gateways — sit behind the same adapter interfaces regardless of where the platform runs. A bank running on-premises and a bank running in Azure are exercising identical origination logic and identical resilience policies; only the underlying messaging, storage, identity, telemetry and secrets providers change, and they change by configuration rather than by code. That is what allows a single codebase of independently deployable .NET 9 Azure Functions services and a Next.js portal to serve both deployment models without forking.

Frequently asked questions

Which core banking system does WPB integrate with?

WPB integrates with Finacle as the core banking system. Finacle is the system of record for customer and account data and the engine for the financial execution of a loan: WPB calls it to create a CIF and transactional account for new-to-bank customers, mark the customer's limit, book the loan with all its parameters (branch, scheme and employer codes, repayment account, tenor, interest rate and so on) and perform full, partial or final disbursement. It is also used to verify salary credits for existing customers. The integration is reached through an adapter wrapped in Polly retry and circuit-breaker policies, like every other external system.

What happens if an external service like CRB is temporarily unavailable?

The platform is built to degrade gracefully rather than fail outright. Every external call is wrapped in a Polly retry policy of three attempts with exponential backoff, so a transient outage is often absorbed before anyone notices. If a provider keeps failing, the circuit breaker opens after five consecutive failures and pauses calls for a 30-second break, failing fast and protecting the workflow instead of letting it hang. On top of that, compliance results — including CRB — are cached for 24 hours, so if an applicant was already screened that day, the platform reuses the cached result rather than re-querying an unavailable service.

Can the platform run without the cloud integrations?

Yes. WPB is designed for dual deployment with feature parity: it can run entirely on a bank's on-premises Kubernetes cluster, using RabbitMQ for messaging, MinIO for object storage, Keycloak/LDAP for authentication and OpenTelemetry with Prometheus for telemetry — or it can run on Microsoft Azure as a Marketplace managed application using Service Bus, Blob Storage, Entra ID and Application Insights. The choice is made through environment variables resolved by interface-based dependency injection, so the same business logic and the same lending integrations apply in both. The external lending systems themselves sit behind consistent adapters in either deployment.

To see the integration layer and the full origination workflow in practice, explore the Workplace Banking product page or book a demo.