Compliance Checks in Loan Origination: IPRS, CRB, KRA and AML Screening
The compliance checks behind every workplace-banking loan — IPRS identity verification, CRB credit checks, KRA PIN validation and Comply Advantage AML/PEP screening — how they are orchestrated, cached and reviewed.
Every unsecured check-off loan begins with a question that has nothing to do with affordability: is this person who they claim to be, and is it lawful to lend to them? In the Workplace Banking platform, that question is answered by a compliance layer that runs four distinct external checks against trusted Kenyan and global data sources, feeds the results into a deterministic business-rules engine, and keeps them visible to every reviewer through to approval. This article walks through those checks, how they are orchestrated and cached, where they sit in the workflow, and — just as importantly — where origination screening ends and ongoing anti-money-laundering (AML) monitoring begins. For the wider picture of how scheme lending fits together, see the complete guide to workplace banking.
The four origination checks
The Compliance microservice runs four external checks, each through its own integration adapter against an external authority. None of them is a credit decision in itself; they are the evidence base on which the rules engine and human reviewers act.
- IPRS — identity and bio-data. The Integrated Population Registration System verifies a national ID or passport and returns the citizen's bio-data, which the platform uses to auto-populate the applicant record. This anchors the entire application to a confirmed identity rather than to keyed-in claims, and reduces capture errors at the point of entry.
- CRB — credit history. A Credit Reference Bureau check returns the applicant's performing and non-performing accounts and any arrears. This is the factual basis for the credit-history rules later applied during analysis, not a substitute for them.
- KRA — tax PIN. Validation of the Kenya Revenue Authority tax PIN confirms that the applicant's tax identity is genuine and consistent with the documented identity, supporting both KYC and the documentary requirements gathered at the loan-application document checklist stage.
- Comply Advantage — AML, sanctions and PEP. A screening call checks the applicant against sanctions lists, adverse-media and politically exposed person (PEP) data. This is the financial-crime gate at onboarding: it tells the lender whether the customer carries sanctions or PEP exposure that must be considered before any facility is booked.
Together with a KYC compliance check, these four results form the compliance picture for the file. Crucially, the platform treats them as inputs to be reviewed and reasoned over — not as automatic accept or reject verdicts.
Where the checks run in the workflow
Screening is not a one-off event buried in the back office; it is initiated early and then kept in front of every reviewer.
The first search runs at Customer Application (workflow stage 2), keyed on the national ID or passport number. Running it this early means identity, credit, tax and AML signals are available before the application has consumed downstream effort, so an obvious problem — a failed identity match or a sanctions hit — surfaces before documents are collected and capacity is calculated.
From there, the results travel with the application. At each review stage — notably Document Verification and Data Capture (SCCA) and Credit Analysis (Credit Analyst) — the reviewer works from a split screen showing the application details alongside the full set of search and compliance results. Rather than asking each role to re-run checks or hunt for prior outputs, the platform re-displays the same authoritative results in context, so a Credit Analyst is assessing affordability against the very identity, credit and AML evidence that was retrieved at application. For the full sequence of stages and the roles that own them, see the workplace-banking loan workflow.
Resilience, caching and the adapter pattern
External authorities are exactly the dependencies you cannot control: a bureau may be slow, an upstream API may time out, a network path may flap. The Compliance service is built so that those realities do not corrupt a loan file or stall the queue unnecessarily.
Every external check is wrapped in the adapter pattern, which isolates the rest of the platform from the quirks of each provider's API behind a consistent internal contract. Each adapter is then hardened with Polly resilience policies: a retry policy of three attempts with exponential backoff to absorb transient failures, and a circuit breaker that trips after five failures and holds open for thirty seconds, preventing the system from hammering a service that is already struggling.
On top of that, each result is cached for 24 hours (a time-to-live, or TTL, on the cached value). Within that window, re-displaying results at successive review stages does not require a fresh call to IPRS, CRB, KRA or Comply Advantage. The practical effects are worth spelling out.
| Mechanism | What it does | Why it matters for origination |
|---|---|---|
| Adapter pattern | Normalises each provider behind one internal contract | A change at one bureau does not ripple through the platform |
| Polly retry (3, exponential backoff) | Re-tries transient failures | A momentary timeout does not fail the check outright |
| Polly circuit breaker (5 failures / 30s) | Stops calling a failing service for 30 seconds | Protects throughput when an upstream source is degraded |
| 24-hour result cache (TTL) | Re-uses results across review stages within a day | Consistent evidence for every reviewer; fewer redundant calls |
The caching choice is deliberate: a single application is reviewed by several roles over a short period, and they should all be reasoning over the same snapshot rather than slightly different results pulled minutes apart.
From results to decisions: feeding the rules engine
The four checks supply facts; the business-rules engine turns those facts, together with the customer's own declarations, into deterministic outcomes. This is a rules engine, not machine learning — the logic is explicit, auditable and the same for every applicant.
Several of its rules consume compliance results directly. The PEP check acts on the Comply Advantage screening; CRB rules act on the bureau's performing and non-performing account data; the identity and tax confirmations underpin the KYC position and the existing-facilities check. Other rules in the same engine work on payslip and statement data rather than external screening — the minimum take-home of KES 50,000, the debt-to-income and one-third-of-basic-salary tests, the retirement-age rule (loan maturity must not exceed three months to retirement), the employment-contract-maturity rule, and net-pay verification comparing payslip net pay against bank-statement credits.
Employee verification sits alongside this: the employer confirms the applicant through an agreed mode (a recorded telephone line or email), with the person contacted, date, time and number recorded. Government ministries are exempted at the credit stage because the call-back has already been done by sales, while private entities receive this as enhanced due diligence at credit. How all of these signals are weighed by a human Credit Analyst — and how the rules engine supports rather than replaces that judgement — is covered in credit analysis for unsecured personal loans.
Where origination screening ends and AML monitoring begins
It is important to be precise about scope. The checks described here are onboarding-time screening — the compliance gate at the moment a loan is originated. They establish, at a point in time, that the customer's identity is genuine, their credit position is known, their tax PIN is valid, and they are screened against sanctions, adverse-media and PEP data. That is the start of compliance, not the whole of it.
What it deliberately does not do is watch the relationship over its lifetime. Ongoing transaction monitoring, periodic refresh of a customer-risk assessment, and regulatory reporting are a separate discipline belonging to a dedicated AML platform rather than to a lending-origination workflow. The clean handoff is as follows.
- Origination screening (Workplace Banking): point-in-time identity, credit, tax and sanctions/PEP checks that gate a single loan application.
- Ongoing AML monitoring (the AML compliance platform): continuous transaction monitoring, periodic customer-risk assessment, enhanced due diligence and reporting across the relationship over time.
For the depth of how ongoing screening, watchlists and case management operate, see the AML platform complete guide and the explainer on sanctions and PEP screening. Where an institution needs to design or strengthen the policy framework around all of this, Creodata's financial-crime compliance advisory service addresses the governance layer that sits above both systems. Treating origination and ongoing monitoring as distinct but connected keeps each system focused and the boundary between them auditable.
Frequently asked questions
Why are compliance results cached for 24 hours?
A single loan application is handled by several roles in quick succession — the application is captured, documents are verified, and credit analysis is performed, often within the same day. Caching each IPRS, CRB, KRA and Comply Advantage result for 24 hours means every reviewer reasons over the same snapshot rather than slightly different results pulled at different moments. It also avoids redundant calls to external authorities during a short review window, which reduces load on those services and protects throughput. The cache is a time-to-live window, so results naturally refresh once that period elapses, keeping the evidence reasonably current without re-querying on every screen.
What is the difference between origination screening and ongoing AML monitoring?
Origination screening is point-in-time. It runs the four external checks when a loan is being originated to confirm identity, credit history, tax PIN and sanctions/PEP exposure for that single application, gating whether it should proceed. Ongoing AML monitoring is continuous and relationship-wide: it watches transactions over time, refreshes the customer-risk assessment periodically, escalates to enhanced due diligence where warranted, and supports regulatory reporting. In the Creodata stack, origination screening lives in the Workplace Banking platform while ongoing monitoring belongs to the dedicated AML compliance platform. They are connected but deliberately separate, so each remains focused and the handoff stays auditable.
What happens if a borrower is flagged as a PEP?
A politically exposed person flag from Comply Advantage is a result, not an automatic decline. It feeds the deterministic PEP rule in the business-rules engine and is re-displayed on the reviewer's split screen alongside the rest of the application at every review stage. Reviewers — through document verification and credit analysis — consider the flag in context with the other checks and the customer's declarations before a Credit Analyst and Credit Approver make a decision. Because the audit trail and the rules applied are explicit, the basis for proceeding, declining or applying additional scrutiny is recorded rather than left to opaque judgement.
To see how the compliance layer fits the wider origination flow, explore the Workplace Banking product page, and book a demo to walk through the four checks, the split-screen review and the rules engine against your own scheme parameters.