One signed question.
Every lender's answer.
Learn, in one consented call, whether a borrower who looks clean to you is already servicing loans across the ecosystem. Then read the bureau file, the M-PESA statement and the score as one decision you can defend.
Measured on live books · 16 September 2026
Every report answers one question a credit officer actually asks.
Turn a card for where the answer comes from and what it returns. Ecosystem answers are free to a contributing member; bureau-backed answers carry the bureau's cost and a stated fee.
“Is this ID real, and is it the person in front of me?”
Identity Verification
Answered from the ecosystem's live books.
“Are they in default right now, anywhere in this ecosystem?”
Delinquency Status
Live from member books, where the bureau's equivalent is a monthly submission cycle behind.
“Every credit account on file, and how each one is performing.”
Credit Info
The same bureau bytes a direct Metropol integration returns, re-read as a decision: live totals, concentration, arrears staleness, and the accounts that actually carry the risk.
“Everything on file, read as a decision rather than as a dump.”
Credit File
Totals, concentration, staleness and stacking velocity computed on top of the bureau's own fields — none of which appear on Metropol's own report.
“Is this borrower, who looks clean to me, servicing loans elsewhere right now?”
Ecosystem Exposure
No bureau can sell this. It is answered from live books in under half a second, and it is free at the point of use.
“What is the network's number on this person, and why?”
Interchange Score
Reason codes from SHAP, and a model trained on outcomes the bureau never sees — including loans other members declined.
“What can they actually afford to repay each month?”
Cashflow & Affordability
M-Pesa statement features computed from the rail itself, not a bureau's income model.
“Who is this borrower shopping with right now?”
Intent Signal
Applications across members in the last 30 days, approved and declined. A bureau sees neither.
“When and how do we actually reach this person?”
Contactability
Built on 1.34M call dispositions and 150K promises-to-pay already in CollectBox. Note the number collision: Metropol's own report 22 is a 12-month account history and is NOT in Micromart's contract (E029).
“How does this borrower compare with their peers across the ecosystem?”
Cohort Benchmark
Answered from the ecosystem's live books.
The bureau's data, read as a decision.
All 13 Metropol report types, pulled through one signed call. The bureau's JSON is a list of codes; we hand back the same answer three ways, with the regulatory notices exactly where the bureau puts them.
- A PDF on the Interchange letterheadTotals, concentration, staleness and stacking velocity, with every panel saying whose figure it is.
- JSON with every code in wordsDelinquency, product type, account status and sector carried as value and meaning.
- The bureau's response, unchangedKept byte for byte beside its SHA-256, so a dispute starts from what the bureau actually said.
- The account ladder as CSVEvery account, one row, ready for a spreadsheet or a model.
The borrower who looks clean to you.
2,252 borrowers on published books are servicing loans at more than one lender. A bureau learns that a month later. The Interchange answers now, from live books, without anyone seeing a national ID.
Illustration · members unnamed · timings drawn
The ID becomes a token inside your own node. The Registry never sees it.
Published filters rule out members who cannot hold the borrower. They never learn you asked.
The rest answer with aggregates: counts, a band, a bucket. No names, no loan IDs.
Every call, granted or refused, lands in a hash-chained log anyone can re-verify.
A locked M-PESA PDF in. An affordability decision out.
Upload the statement Safaricom emailed and the password from their SMS. Watch it decrypt, parse, post to ledgers, audit and score, then download the result. Crunch one, or a queue of them. The PDF and its password are never stored.
Watch the theatre- 1Decrypt the statement
- 2Parse every transaction
- 3Extract income and spend
- 4Post to ledgers
- 5Audit for gambling and other lenders
- 6Score and size the instalment
Security that is enforced in code, not promised in a contract.
National IDs and phone numbers become OPRF tokens inside the member's node. Nothing downstream ever holds one.
Every call presents a consent reference bound to the borrower's token. Another borrower's consent buys nothing.
Each request carries an Ed25519 signature over its exact bytes. Nobody can ask in a member's name, including us.
Every decision is hash-chained. Edit one entry and every entry after it stops verifying.
A member that stops contributing stops being able to query, automatically and without a meeting.
Books stay with their owners. Members answer about their own customers, in aggregates only.
Already integrated with the bureau? Change a URL and a key.
Same request fields, same report integers, same has_error and api_code. What changes is the signature, which no one can forge, and the answer, which arrives already read.
{
"report_type": 12,
"identity_number": "880000088",
"identity_type": "001",
"loan_amount": 8000,
"report_reason": 1,
"consent_ref": "CN-…",
"format": "pdf"
}