Building a Rate Engine for 10 Countries: What We Learned
This is the first in a series of build-in-public posts. No marketing. No positioning. Just the honest story of building something hard.
When we set out to build a rate engine for infrastructure financing across Latin America, we thought the hard part would be the math. The real hard part was finding honest data.
Version 1: The Corporate Rate Mistake
Our first rate model used corporate borrowing rates as benchmarks. The logic seemed sound: if a Chilean corporation borrows at 7%, we should be able to offer competitive rates starting around 8-9%.
We were wrong. Catastrophically wrong.
Corporate rates have nothing to do with what SME operators pay. A Chilean corporation at 7% and a Chilean PYME at 11% are operating in different financial universes, same country, different planets.
When we showed our v1 rates to operators, the feedback was immediate: "This is lower than what my bank quotes me. How?" The answer, we were benchmarking against the wrong segment, wasn't something we wanted to ship.
The OECD Pivot
The turning point was discovering the OECD's SME Financing Scoreboard. For the first time, we had systematic, country-level data on what SMEs actually pay:
| Country | What We Used (Corporate) | What SMEs Actually Pay | Error |
|---|---|---|---|
| Chile | 7% | 11% | -4pp |
| Peru | 7% | 20% | -13pp |
| Colombia | 14% | 21% | -7pp |
| Mexico | 10% | 16.5% | -6.5pp |
| Brazil | 17% | 24% | -7pp |
| Uruguay | 12% | 21% | -9pp |
Our v1 engine was underpricing risk by 4-13 percentage points. If we'd launched with those rates, we would have been making promises we couldn't keep, or building a model where LPs lose money.
Version 2: Country-Level Calibration
V2 introduced the concept we still use today: every country has its own base rate, calibrated to actual PYME market data, not corporate benchmarks.
The base rate represents what a mid-quality asset (risk score 4 out of 7) should cost in each market, considering:
- Local deposit rates (what LPs can earn alternatively)
- PYME borrowing rates (what operators currently pay)
- Country risk premium (EMBI spreads, political stability)
- Regulatory environment (enforcement reliability)
This immediately solved the pricing honesty problem. Our rates were higher than v1, but they were real. An operator seeing a 12% rate in Peru knew exactly where it sat relative to the bank's 20% and the informal market's 30-40%.
Version 3: The LP Floor Problem
V2 got the operator-side pricing right, but we'd neglected the other side of the equation: LP economics.
An investor deploying capital in our pools needs to earn more than their local deposit rate, significantly more, to justify the illiquidity and credit risk. If a Peruvian deposit pays 4.5%, an LP won't accept 6% from an infrastructure pool.
V3 introduced the LP viability floor: every rate must be high enough that, after the 0.5% admin fee on distributions, the LP earns at least depositRate + 4.5pp.
This constraint raised rates in some markets, particularly in dollarized economies (Panama, Ecuador) where deposit rates are low and the floor becomes binding. It's counterintuitive: we had to increase some operator rates to build a sustainable market that would attract capital.
Version 4: The Improvement Guarantee
V4 solved the hardest UX problem: showing operators that verification pays off.
In v3, an operator in certain markets (Chile, Panama) could run a simulation, see their indicative rate, go through full due diligence, and get... the same rate. No improvement. Verification felt like a gate without a reward.
V4 introduced the guaranteed improvement mechanism:
potentialRate = max(depositRate + 6, rawRate - 2pp)indicativeRate = max(rawRate, potentialRate + 1pp)
The indicative rate is set at least 1pp above the potential rate. Always. In every market. For every risk profile. This means every operator who completes verification sees a concrete improvement, even if it's modest.
For some markets, this meant raising the indicative rate above what the pure model would suggest. In Chile, the raw model says a score-4 operator should pay 10.5%. But to guarantee 1pp of improvement (potential at 10.3%, rounded), we set the indicative at 11.3%.
Is this mathematically "honest"? Yes, because the improvement is real. The indicative rate reflects the cost before verification reduces information asymmetry. The potential rate reflects the cost after. The gap represents the value of verified data.
What We Got Wrong Along the Way
Mistake 1: Uniform spread tables. V1-V2 used the same spread-vs-score table for all countries. This ignored that a score-4 operator in Peru faces completely different market conditions than a score-4 in Panama. V3+ uses country-specific calibration.
Mistake 2: Ignoring bank accessibility. We initially treated all asset types equally. But banks readily finance real estate (easy access, low rates) and won't touch data centers (hard access, high rates). The industry adjustment now reflects this: data centers get -0.25% (because DOB's value-add is highest), while real estate gets no adjustment (banks serve this market well).
Mistake 3: Overcomplicating the output. V1 showed operators their 7-factor breakdown, the spread calculation, the jurisdiction adjustment, and the industry modifier. Operators don't care about any of this. They care about: "what's my rate?" and "what's my monthly payment?" V4 shows exactly two numbers. The complexity is internal.
The Current State: 12 Countries, 7 Factors, ~700 Rate Combinations
The v4.4 engine produces an indicative rate for any combination of:
- 12 countries (Chile, Peru, Colombia, Mexico, Brazil, Ecuador, Costa Rica, Panama, Uruguay, Paraguay, Other LATAM, Outside LATAM)
- 10 asset types (data centers, energy, SaaS, real estate, fleet, mining, industrial, agriculture, health, other)
- 7 risk scores (0-6, based on 5 binary factors + 2 continuous factors)
That's roughly 840 possible combinations, each producing a unique rate. The model is recalibrated quarterly using central bank data, OECD publications, and EMBI spreads.
What's Next
Two things we're actively working on:
Predictive accuracy. As we accumulate simulation data (each simulation is a complete risk profile), we can start measuring how well our model predicts actual financing outcomes. Right now, our rates are benchmark-calibrated. In the future, they'll be outcome-calibrated.
Dynamic country data. Currently, base rates are updated quarterly by hand. We're building automated pipelines to ingest central bank publications and update base rates in near-real-time. When Peru's BCRP changes its reference rate, our engine should reflect it within days, not months.
The Lesson
Building a rate engine taught us that the hardest problem in fintech isn't the math; it's the data integrity. Anyone can build a formula. The challenge is feeding it honest inputs, testing the outputs against reality, and being willing to raise your rates when the data says you should.
The temptation in fintech is to show the lowest possible rate; it converts better. We chose to show honest rates. It converts slower, but it builds something that actually works.
This is Build in Public #1. Future posts will cover the journey from simulator to funded asset (#2) and the simulator as a dataset flywheel (#3). All rate data referenced is from the DOB Capital rate engine v4.4 (May 2026).
