A fintech on the architectural decision that eliminated loan application fatigue and accidentally built a moat in the process.
When we started building UMI, we thought we were building a comparison tool. That seemed like a reasonable solution to the problem.
The Philippines had a booming consumer credit market and a completely fragmented experience. In any electronics store you'd find three or four lenders competing for the same customer at the checkout counter, each with their own agent, their own form, their own approval timeline. Aggregate the options, surface the best rates, take a margin. Simple enough.
We came into this with some relevant experience. Andrey Gurin and the team had built Direct Credit, a POS-lending aggregation business that reached a billion dollars in annual loan volume before being sold in 2021. But at Direct Credit, the issue was friction. Customers had options and the process was tedious. In the Philippines, the issue was that customers were being rejected and walking out empty-handed. Approval rates at individual lenders were low enough that most applicants at any given counter would leave without a loan. That's a different problem from friction. Aggregating rates doesn't help someone who can't get approved anywhere.
What we saw in the stores
What shifted our thinking wasn't the data but time spent at the checkout counter watching what actually happened. A customer would come in wanting to finance a phone or a television. A lender's agent would spend twenty minutes on their documents and then say no. Another agent from a different lender would try. Same result, different explanation. The third agent, having watched two colleagues fail, would often decide not to bother. The customer would leave. The merchant would shrug and move on.
No one was calculating, before the formal application, whether this particular customer was likely to get approved by this particular lender — given what was already known about their documents and income.
Each lender's agent was working in isolation, without any pre-screening. Customers cycled through rejection after rejection, each one a hard credit inquiry that damaged their score, because no one had thought to match them to the lenders who might actually say yes. We had been building the wrong thing. What the market needed wasn't a comparison layer for people with good options but a routing layer for people whose chances of approval varied substantially across lenders.
Why the back end was the wrong place to solve it
The obvious engineering response was to build everything on the back end: take the application, push it through each lender's API, normalise the responses, surface the best results. That's how most platforms in this space approach it.
We tried it. The problem is that each lender has its own field requirements, its own consent language, its own data formats. Every time a lender changes something on their end, which happens more often than you'd expect, something breaks. Add ten lenders and you have ten separate maintenance problems that don't compound well. The system becomes fragile in direct proportion to its own growth.
So we moved the integration work to the front end instead. We built a single application form, structured to satisfy all of our lending partners from the moment of data collection. We had to sit with each bank and work through exactly what they needed, field by field. Some of them had genuinely never been asked to specify their requirements at that level of detail before, so the conversation itself was different from what they were used to.
The first few integrations were expensive. But once the input contract was defined properly, each lender we onboarded after that was less work than the one before. The product team stopped spending its time fixing broken integrations and could now actually build things.
The matching engine we built on top of this could then pre-qualify applications before formal submission, showing customers the offers they were statistically likely to receive, including options where a higher down payment would unlock approval. Fewer wasted enquiries. Better outcomes at the counter.
What this means if you're building on top of external partners
The pattern we ran into is fairly common in platforms that depend on multiple external counterparties: banks, suppliers, regulated third parties, APIs you don't control. The instinct is to treat integration complexity as a back-end problem, something to be abstracted and handled out of sight. That works reasonably well, until it doesn't.
Pushing complexity downstream doesn't eliminate it, but converts it into ongoing maintenance that grows with the number of partners and compounds with every change any of them makes.
There's also a subtler cost: when you defer the work of defining a proper data contract with each partner, you lose the chance to do it well. You accumulate workarounds instead, and workarounds tend to become permanent. The right moment to establish how data flows between you and a partner (what format, what fields, whose requirements take precedence) is before you write the integration, not after something breaks.
The practical consequence of getting this right showed up when QRPh, the Philippines' national QR payment standard, became available. Because we had decomposed the processing into clean, separated layers at the front end, adding QRPh as a payment rail didn't require rearchitecting the rest of the system. We could slot it in. Customers could then complete the entire journey paying via a single QR code, across any bank or e-wallet.
UMI became the first loan aggregator in the Philippines to support this, which further simplified what had been a fragmented experience at the counter. That kind of integration is considerably harder to do cleanly when the processing layers are tangled up in back-end workarounds from earlier compromises.
The work that enabled it (data contracts, field-level specification with each bank, agreeing on whose requirements take precedence) doesn't make it onto a product roadmap. It's not visible to users and doesn't generate a compelling demo. Teams defer it, build around it, and end up carrying the debt until a new partner request or a regulatory change makes the accumulated shortcuts impossible to ignore. We did this too, for a while.
The moat we didn't plan for
Something we hadn't anticipated: once a merchant was using our agent app, they had access to our full lender network through one interface. Moving away from that would mean starting the integration process over from scratch with whoever they moved to. We didn't design this as a retention mechanism. It emerged as a side effect of having solved the integration problem properly.
The defensibility came from solving a tedious technical problem correctly, not from any strategic thinking about lock-in.
This seems worth noting because the instinct in product development is usually to identify moats deliberately and build toward them. In our case, the structure that made switching costly was a consequence of doing unglamorous infrastructure work well — sitting in rooms with bank compliance teams, arguing about field names, building to a specification that nobody wanted to own. That work didn't feel strategic at the time. It just needed to get done.
What we'd do differently
We spent too long on the comparison tool framing when customers weren't struggling to compare options but to get approved at all. Identifying the right problem faster would have saved significant time and money.
What eventually got us there was being present in the stores long enough to stop seeing what we expected to see. That sounds less profound as advice than it actually is in practice. Most teams engage with the market through intermediaries: metrics, customer interviews, sales feedback. Those aren't useless, but they tend to confirm the frames you already have. The thing that shifted our thinking was direct contact with the moment of failure, repeated enough times that the pattern became impossible to ignore.
