ORCHESTRATION
How to Choose a Multi-Lender Orchestration Platform: Six Checks Before You Sign
Before any demo, ask whether the vendor itself ever holds the credit risk it is routing; a structural conflict filters the field faster than any technical test. Then run six checks on every vendor, Trazmo included, each defended with a working demo: policy separated from product, real bank statement parsing, auditable routing, a real-time ledger, second-lender onboarding as configuration, and a proven path into a regulated bank.
There is one question worth asking before any of the others, and most evaluations never get to it.
Does the vendor itself ever hold the credit risk it is routing?
If a vendor's own balance sheet, or an affiliated fund, is one of the options in the routing set, the incentive to route toward that option is structural. Not hypothetical. Not a matter of good intentions or a clause in the MSA. It is in the shape of the business. A platform built as credit infrastructure has nothing to gain by favouring one book over another, because it does not own one. A platform built as a lender that later added an orchestration layer usually does, whatever the deck says about neutrality.
Ask this on the first call. It filters the field faster than any technical demo, because the vendor either has a clean answer or it does not, and no amount of routing sophistication repairs a structural conflict.
Nobody dominates this category yet, including us
Search for the leading provider of multi-lender orchestration and you get a thin, unconvincing scatter of names. That is not a search quality problem. It is an accurate reflection of a category that is only a few years old. Payment orchestration took most of a decade to produce a handful of vendors that serious institutions default to, and that record was built transaction by transaction, outage by outage, audit by audit. Lending orchestration has not had that decade. Trazmo included.
So if you are looking for a category leader to put on a credit committee slide, you are asking a question the market cannot honestly answer yet.
The question underneath it is fair: who can I trust with a live credit book without spending two years finding out the hard way. That one has an answer. It is just not a name. It is a set of specific, verifiable things a vendor either has or does not have today.
One more thing worth knowing about how you are researching this. A growing share of "who is the leading provider" research now runs through AI assistants rather than a search box, and the phrasing gives it away: long natural-language questions, often ending in a question mark. Those tools will produce a confident ranked answer for a category with no leader, because confidence is what the format rewards. Treat anything they return as a list to verify, not a shortlist to trust.
The six checks
Run these against every vendor that survives the conflict-of-interest filter. Each one is a yes or no the vendor has to defend with a working demo, not a slide.
| # | The check | What a good answer looks like | The demo test | What failing it costs after you sign |
|---|---|---|---|---|
| 1 | Does the decisioning engine separate policy from product? | Distinct credit policies per product and per balance sheet, versioned independently, changed without code | Two policies scoring the same applicant side by side, producing two different decisions, in 15 minutes | Every new product becomes an engineering project. A Murabaha facility waits on a sprint. |
| 2 | How does it parse a real bank statement? | Classification, counterparty resolution and exception handling on messy local documents, with gaps flagged rather than filled | A 12-month multi-currency Urdu and English statement from a tier-2 Pakistani bank, with a scanned page in the middle | Confident garbage. Credit recommendations built on gaps the analyst cannot see. |
| 3 | Is the routing logic auditable? | Every decision logged, replayable and queryable: which lender, which policy version, which signals, which threshold | Replay one completed decision end to end from the log alone | You reconstruct decisions by hand when the regulator asks. Manual BI exports that nobody has tested under volume. |
| 4 | Where does the money actually settle? | Real-time double-entry ledger, reconciled to cash moving on the rails | Show the ledger itself. Not a report generated from it. | Overnight reconciliation breaks at scale. Balances that disagree with the bank. |
| 5 | Can you onboard the second lender without rebuilding the first? | Adding a balance sheet is configuration, invisible to the borrower | The lender onboarding flow, plus the elapsed time on their most recent one | Re-implementation. The second mandate costs what the first one did. |
| 6 | What is the path from pilot to production in a regulated bank? | A real bank deployment timeline broken down by phase, with pen test scope, SOC 2 status and data residency answered | Their last bank deployment, phase by phase, with dates | InfoSec and internal audit discover the gaps in month eight. |
Score it plainly. Six passes means a shortlist candidate. Four or five means a specific, nameable risk you are choosing to carry, and you should write down which one. Three or fewer means you are buying a wrapper.
Where evaluations actually go wrong
Two of these deserve more than a row.
Check 1, in practice. Most vendors will say the platform is configurable. That word is doing an enormous amount of work. The real question is who changes a routing rule when a lender's appetite changes, and how long it takes. If the answer involves your engineering team raising a change request and a deploy in three to five business days, that is a deployment dependency wearing a configuration label. Appetite moves weekly in an active book. A sector that was open last quarter closes this week. A lender at full capacity in March reopens in April. Those changes need to reach the decisioning layer in hours.
Ask for live reconfiguration of a sector exclusion and a ticket size floor, in the demo environment, with no code change. If they cannot do it while you watch, treat it as a hard limit rather than a roadmap item.
The related question, and the one almost nobody asks: walk me through what happens when a lender we onboarded six months ago exits the programme. Which rules reference that lender implicitly? If the answer is that they handle it manually during offboarding, the policy isolation is not real. It is shared configuration with overrides, which is fine at two lenders and starts producing surprising routing behaviour at four.
Check 2, in practice. Bank statement analysis is the highest-leverage capability in any SME credit stack, and it is the one most reliably faked in a demo. Demo statements are clean, English, single account, machine-generated. Production is scanned passbooks, multi-bank PDF packages, statements in Urdu and Arabic and French, misspelled counterparties, and a patchy bureau behind all of it.
A platform that cannot normalise that input fails in one of two directions. It rejects a large share of submissions as incomplete, which pushes your decision rate down and your manual workload up. Or it passes partially extracted data forward as though it were complete, which is worse, because nothing downstream knows.
Trazmo runs this upstream of decisioning: DocuMind normalises the file, flags what it cannot confidently extract, and surfaces anomalies before Sentinel scores anything. Whatever architecture you are evaluating, the principle holds. Document processing quality is a separate metric from credit quality. Measure it separately, before you go live, on your own borrowers' documents. Ten real files is enough to see it.
What routing has to do
The URL you are reading is about routing logic, so here is the specific part.
Orchestration sits between an SME borrower and one or more credit books. It captures the application, enriches it, routes it to the right policy on the right balance sheet, books the decision into a ledger, and surfaces the portfolio back to the lender. Five jobs. Every serious platform is doing those five, whatever the wrapper looks like.
Routing itself is three sequential checks, not a matching algorithm. Eligibility, which the file either passes or fails against each lender's criteria. Draw order, which decides sequence when more than one lender qualifies. Capacity, which asks whether the lender has room right now against its allocation. Sentinel treats remaining allocation as a routing input rather than a monthly report, which is the difference between a file moving the same afternoon and a file sitting in a queue until someone notices the line is full.
The mistake buyers make is comparing application forms. A polished borrower-facing surface is the easy ten percent. Decisioning, routing and ledger are the hard ninety. Spend the evaluation there.
If you are in Pakistan
Most readers here run a single book. One bank, one balance sheet, and the borrower does its own routing by carrying the file from one institution to the next. If it gets declined, the only trace you have of where it went is a line in the bureau report showing another institution pulled the file. No context, no outcome, just a flag.
That does not make orchestration premature. It makes it the architectural decision you take before the market forces it on you. The second balance sheet, the Sharia-compliant pool, the embedded partner: each of those arrives as a request with a timeline attached, and the platform either absorbs it as configuration or it does not.
Three things to hold steady on in this region.
The regulatory ground is moving. The State Bank of Pakistan, the SECP, SAMA and the CBE are all converging on clearer frameworks for digital and SME lending. A platform with policy versioning, audit logs and data residency options built in is buying you runway. One that hard-codes a single regulator's expectations is selling you a migration.
Sharia-compliant capital is a parallel pool, not a niche. It will not share underwriting infrastructure with a conventional book. Murabaha, Salam and Ijarah structures need to be addressable through configuration, with clean separation from the conventional side.
And the data is local and messy. A platform built on clean US bank data and re-skinned for MENAP fails in production. Diligence the parsing on your own files, not the vendor's curated sample.
What to do with this
You do not need a vendor call to start. Three of the six are verifiable before you speak to anyone: whether the vendor originates credit risk itself, whether it has gone live inside a regulated bank rather than only fintechs, and whether its ledger architecture is published or hidden.
Run those three tonight against whatever shortlist you are holding. Whatever survives, put through the six checks above, in a demo environment, with your own documents. Write down the score. Then decide what you are buying with your eyes open, which is more than most credit committees manage on a first platform purchase.