Turning messy lender submissions into credit reports institutions trust

A credit information company sits between a country's lenders and its borrowers. Banks, microfinance institutions, and non-bank lenders submit loan performance data every cycle, and the bureau returns the credit reports and scores that decide who gets credit and at what price. This client, a credit information company licensed under a central bank credit bureau regime in South Asia, had built its original platform around batch file loads and a manual correction queue. That design held while the member base was small and submission formats were consistent.

It stopped holding as membership widened. Each institution submitted in its own layout with its own quirks: borrower names transliterated differently across files, national identity numbers with transposed digits, addresses that never agreed, dates in conflicting conventions. The matching logic could not tell whether records described the same borrower, so operations staff decided by hand. Correction queues backed up, disputed records were hard to trace back to the submitting lender, and member institutions began questioning the accuracy of the reports they depended on.

Kentro was engaged to rebuild the core: the submission pipeline, the entity resolution engine, report assembly and scoring attributes, dispute handling, and the API layer members use to pull reports, all under audit and compliance controls a central bank examiner could inspect.

Credit bureau infrastructure has an unforgiving property: the product is only as good as the worst data submitted to it. The engagement had to fix quality at the point of entry, not paper over it downstream.

• Messy identity data with no reliable key.: Borrower names arrived in competing transliterations, identity numbers carried entry errors, and secondary fields like addresses and dates of birth disagreed across lenders. Deterministic joins missed real matches and merged distinct people.
• Every member submitted differently.: File layouts, code lists, and update conventions varied by institution. The old loader accepted almost anything and pushed the cleanup burden onto bureau staff after the fact.
• Disputes with no thread to pull.: A borrower challenging a record triggered manual investigation across archived files. Nothing linked a reported tradeline back to the original submission that produced it.
• Compliance evidence assembled by hand.: Regulator requests meant reconstructing who accessed which report and why from scattered logs, and proving that corrections had actually propagated to later reports.

Kentro rebuilt the platform as a set of services around an append-only submission store, so every field in a credit report traces back to the exact file, row, and member institution that furnished it. Ingestion, matching, reporting, and disputes all operate on that same lineage.

• Contract-first ingestion.: Each member institution operates against a versioned data contract. Submissions are validated at the gate for structure, code lists, and referential integrity, with rejects returned as machine-readable error reports the lender fixes at source. Accepted batches load idempotently, so resubmissions never duplicate tradelines.
• Layered entity resolution.: Deterministic matching on national identifiers handles the clean cases. Probabilistic matching then scores candidate pairs using phonetic and transliteration-aware name normalization, address standardization, and date tolerance. Confident matches merge under survivorship rules, borderline scores route to a clerical review queue, and every match decision is stored with its evidence.
• Report assembly on consolidated profiles.: An attribute engine computes payment history, exposure, and inquiry attributes from the resolved borrower profile and feeds the scorecard. Reports render from that same profile whether requested through the portal or the API, so members see identical data on every channel.
• Disputes wired to lineage.: A dispute case links directly to the tradeline and its originating submission, routes to the furnishing institution with response timers, and applies corrections back through the standard ingestion pipeline, so the fix propagates to future reports and the audit trail stays intact.
• Member APIs with enforceable controls.: REST APIs with token-based authentication and mutual TLS give member institutions programmatic report access under per-member entitlements and purpose-of-use logging. Every report pull lands in the append-only audit log the compliance team works from.

The bureau now runs on data it can defend. The operational shifts mattered more to the client than any dashboard.

• Manual correction stopped being the job.: Bad submissions bounce back to lenders with actionable error reports instead of landing in a bureau cleanup queue. Operations staff now handle the borderline match reviews the engine flags, and little else.
• Members pull reports inside their own systems.: Institutions that used to wait on file exchanges query reports through the API from within their loan origination flows. New members onboard through contract configuration rather than custom integration work.
• Disputes resolve along a visible thread.: A challenged record traces straight to its source submission, corrections propagate automatically, and the borrower-facing team can see case status without chasing the data team.
• Regulator questions answered from the log.: Access history, match decisions, and correction trails come out of the audit store as evidence rather than reconstruction. Compliance reviews moved from a scramble to a query.