Client impact · Quasi-financial group
No more phoning a sister company to check the limit
Micro-lending, factoring, leasing, guarantees and pawnbroking each kept their own customer book, so one borrower carried five balances across five subsidiaries. We did three things: merged the customer and group-customer keys, configured an approval engine that blocks disbursement until conditions precedent are met, and put indicator definitions and alert dispositions into one loop.
The institution
One division, five businesses, five customer books
The funding is shareholder capital plus bank borrowing and inter-institution cooperation. The businesses are micro-lending, commercial factoring, financial leasing, guarantees and counter-guarantees, and pawnbroking. Three layers share the work: group risk sets limits and definitions, subsidiaries run contracts, collateral and disbursement, and back-office lines carry the books.
This was not a greenfield. Most subsidiaries already ran their own ledgers or mature systems and could produce a business-line report. What no one could produce was the group view: one natural person holding two customer numbers in two companies, a parent and its subsidiary double-consuming limits across the guarantee and pawn books, invisible in real time to anybody.
The constraints are hard: supervisory and reporting duties differ per licence, approval chains differ, and conditions precedent — security in place, collateral registered, signed and imaged documents — have to block inside the system rather than surface at inspection.
Before the change: where the effort went
This describes the work and how it was consumed. It states no delinquency or non-performing ratio: outcome metrics move with the portfolio and the macro environment, and presenting them as a software result would be dishonest.
| Step | Who carried it | How the effort was spent | Why it never closed |
|---|---|---|---|
| Customers and limits | Subsidiary operations staff and group risk | One borrower with several customer numbers and several balances; limit checks settled by asking around and phoning | No group-customer consolidation rule, so each book was internally correct and collectively blind |
| Indicator computation | Group risk, quarterly, by hand | The 18 indicators re-derived from subsidiary reports in a second spreadsheet, then reconciled at quarter end | Definitions never landed on fields and sources, so the method could change between quarters unrecorded |
| Approval and conditions precedent | Business, legal and finance, offline | Security, registration, signatures and imaging checked against manual lists; disbursement released on missing conditions and ratified afterwards | Checks and the payment instruction sat in different places, so prevention depended on memory |
| Delinquency and recovery | Subsidiary business and legal, separately | Arrears registers, collection notes, litigation, outsourced recovery and write-offs in parallel sets; receipts hard to attach to a contract and instalment | Classification, impairment and business status did not speak to each other, so group exposure lagged the facts |
The judgement
Group limits are a master-data problem, not an approval problem
Moving five approval processes onto one screen only digitises paper. What the group actually lacks is the judgement that these are the same borrower: who belongs to whom, how controlled affiliates consolidate, how two same-named entities are told apart. Without those rules the limit model computes five individually correct numbers.
So deliverable one is the group-customer consolidation and limit-consumption rule table. Deliverable two is workflow configuration.
- Merge the customer before merging the limit
- Limit and utilisation kept separate, consumption live
- No conditions precedent, no payment instruction
- Indicator definitions and thresholds versioned
Three steps we took
Merge the customer, block the payment, close the alert
Subsidiary business systems stay in place. Three classes of fact move up to group level: the customer and group relationship, the limit and its utilisation, and risk indicators with their dispositions.
01 · Master data
Customers and group limits
One customer key per person and entity, with consolidation rules for group customers. Authorised limit and drawn balance are separate fields, cross-business consumption is visible in real time, and an override requires explicit approval with a stored reason.
- Deliverable: consolidation rule table
- Deliverable: group limit register
- Reviewed by: group risk and each business head
02 · Workflow
Approval engine and conditions precedent
Flows and permissions follow each business’s own approval logic. Security status, registration, interview records and document imaging act as pre-disbursement checks: if they fail, the payment instruction is not produced. The mobile approval experience stays consistent.
- Deliverable: condition checklist and flow config
- Deliverable: override path with audit trail
- Reviewed by: legal, finance and internal audit
03 · Indicators
Risk indicators and the alert loop
The 18 indicators plus custom ones get a definition table with data source and algorithm version. Hits route into a review queue where the disposition owner, the conclusion and the miss list all stay in the system.
- Deliverable: indicator definition table and versions
- Deliverable: alert review queue
- Reviewed by: risk and the business line, jointly on thresholds
Modules and integrations in this scenario
Module names follow the company’s published product list; how deep the platform couples to existing business systems is settled in the assessment.
Acceptance measures
Same formulas, read as group — business line — accounting
Three of the four published measures are used. In the consistency formula the tiers are read here as group risk basis — business-line basis — accounting basis; alert precision is assessed on limit breaches and asset-status warnings. Not one word of the formulas is changed; we only add how the numbers were taken.
How we recomputed them here
| Measure | Calculation (as published) | Recomputation in this engagement | Sample and timing |
|---|---|---|---|
| Definition consistency | Share of identical metrics where the three tiers agree with zero variance | Four metrics — authorised limit, drawn balance, days past due, security in place — compared per customer across group, business and accounting; a variance closes only when the consolidation rule, the date or the definition explains it | Sample must include cross-business group customers and small affiliates; single-business names alone hide the defect |
| Alert precision on review | Share of triggered warnings confirmed as real risk by the business | Breach, anomaly and maturity warnings each store an owner and a conclusion; confirmed share is computed quarterly and misses are listed separately so "no false positives" is never read as "no misses" | Reported by warning class across two full quarters |
| Manual fallback hours | Overtime hours during filing season ÷ people involved, from system-captured effort | Counted only for limit checks, re-deriving indicators and manual condition checks, from logged effort rather than recollection | Reported per reporting and computation cycle, separate from implementation hours |
Group risk earns its place not by adding a signature, but by making a breach visible before the payment instruction exists.Catalpa delivery methodology
500+
institutions served on the platform (company disclosure, not this group)
5.6RMB tn+
assets covered (RMB, platform book basis)
30%+
state-capital share (company disclosure)
100+
software copyrights registered (company basis)
Where this approach does not apply
A single-business licensed institution that already reports straight to its supervisor usually gains more from reviewing its indicator definitions than from group-level modelling. And where the holding company takes only a financial stake and carries no responsibility for a consolidated risk view, unified limits and payment blocks simply teach the two layers to blame each other. Set that governance boundary on paper first; the system is the second step, not the first.
Questions specific to a quasi-financial portfolio
Mechanism answers. They promise nothing about asset quality, supervisory determinations or loss outcomes.
How do you merge customer master data across five businesses?
How far do you backfill legacy contracts?
Do subsidiaries have to switch off their existing systems?
Who sets alert thresholds? Won’t risk set them to flatter itself?
Do group limits and payment blocks slow disbursement down?
Next step
Test how many numbers one borrower carries today
In a 45-minute assessment we sample customers across your businesses, size the exposure a consolidated limit would reveal, and set the order: key merge first, condition blocking second.