Not because anyone doubts they can drive. The Ministry of Education simply cannot confirm schooling obtained in a country Chile has no agreement with, and the only route left is to sit back down at a desk.

In Brazil I took documents to one cartório, then to another, and the requirements didn't match. One office asks for a paper the one next door doesn't want at all. Bad luck costs you a month, two, three, spent chasing something that elsewhere wouldn't have been needed.

I've lived in Latin America for over six years and been through this many times. And it's never that the data doesn't exist. It does, it just sits in separate places and travels nowhere. The person pays for that, and pays not in money but in their own time and their own legs.

For the past ten years I've been designing financial systems where these same problems were solved a long time ago.

Why fintech

I spent around ten years in fintech and blockchain projects, most recently in open banking. It's the area I can speak about with confidence, because I designed inside it.

The first explanation that comes to mind is money. Fintech has it, spends it on the best people and the newest technology, and that's why a banking app works better than a government portal.

Convenient, but it doesn't hold up. State budgets differ, and a country with little money really is constrained. Yet where comparable sums go into digital services, the result still comes out different. So the amount isn't the whole story.

The difference lies in the decisions made while designing. Money is a tool and it matters, but the right decisions and the right people matter more. What follows is which decisions carry over.

What carries over

The rule lives in the system, not in the head of the person at the counter

Two cartórios ask for different things not because different people work there, but because the requirement is written down nowhere as a checkable condition. It exists as one clerk's sense of what ought to be in the folder.

In a well-designed financial system that shouldn't happen. Manual checks and contested readings exist in banks too, but the rule is pushed towards being explicit and testable: either the condition is met or it isn't, and the answer shouldn't depend on which window you walked up to. This isn't a question of technology or of budget. It's a decision about where the rule lives.

The system comes to the person first

Nubank sees that every week, on the same day, I send money to my trainer. On that day it asks whether I've forgotten. Nobody asked it to; it noticed a repeating action.

Public systems work the other way round. You have to work out for yourself that something is due, find which agency handles it, and turn up with papers. Even though the expiry date is in the system, the programme opened in that same system, and the risk to your plot is visible there too.

Proactivity is the most transferable thing I know. The person doesn't go looking for the service; the service finds the person.

Complicated things shown simply

Ask a bank today for a chart of upcoming payments or last month's spending and you get something clear. Serious work sits behind that: someone decided the user isn't obliged to understand the data structure.

Public systems, at that same point, tend to publish training materials instead. Instructions, flow diagrams, explanations of how to read the map. A course can teach the subject matter, and that's fine. But when training is needed simply to find your way around a service and work out what it wants from you, part of the complexity has been handed to the person.

Changes take months, not decades

In Chile anything involving documents moves in units larger than years. I lived there three years and I'm not exaggerating. Sometimes it is decades.

In fintech change is fast, and again not because of money. The system is built from modules, the design system is ready in advance, the rules for making changes were agreed before any change was needed, and something new can be released to a slice of users to see what happens. Flexibility is built in at the start rather than achieved later by force.

A large structure can change quickly if it was designed on the assumption that it would have to.

What doesn't carry over

Now the other side, because a list of good practices isn't where this ends.

A fintech product has an owner and a metric. It's clear who answers for the result and what it's measured by. A system running across several agencies has neither: responsibility is spread across participants, and nobody answers for the chain as a whole. I went into this in the previous article and repeat it here briefly, because without it the rest doesn't work.

Then there are things design cannot touch at all. Procurement runs by its own rules and its own clock. Authority is fixed in law. Approving a change can take longer than making it.

And the main difference on flexibility: in fintech a team rewrites a module in a sprint, while in government that same module is often described in a legal instrument. Changing it isn't a development task.

So you can't lift a finished solution out of a bank and drop it into a public system; the constraints around it are too different. But the questions asked before that solution was invented can be asked anywhere. What will we do when the rule changes. Who takes the first step, us or them.

Some will find the comparison strained: a banking app and a cross-agency system are built differently, and I won't argue. But I'm not collapsing one into the other. It's that after ten years in fintech I've seen how these problems get solved, and I can see which approaches are at least worth trying where nobody has tried them.

Where the line is

There's a point where borrowing from fintech turns dangerous.

Connecting agencies exists so that a person doesn't carry certificates around by hand. But that same connectedness turns easily into watching the person: once the data is joined up, building a profile and spotting patterns becomes convenient.

The line runs through which direction the system faces. Nubank's proactivity works for me: it reminds me about my own transfer. The same mechanism turned the other way becomes a note about me, going somewhere I never asked it to go.

So for a public system I'd put the rule like this: records are joined to spare the person work, not to see them more clearly. It doesn't take much. Agencies understanding the same thing by the same person and the same plot. One able to ask another for confirmation and receive it, rather than sending someone off for a piece of paper. The person able to see what stage their application is at. That's enough, and no dossier is needed for any of it.

Regulation sets the line, and public systems are no less supervised than commercial ones. But the line becomes real through architecture: what data is reachable, by whom, for what purpose, and what of it stays visible to the person.

In practice

When I put together the concept for agricultural infrastructure in El Salvador, some of these decisions went in without my thinking of them as borrowed from fintech. Looking back, they were.

First, the system comes to the person on its own. The assistant doesn't wait to be asked: it says that rust has been spotted on a plot, that a moisture risk is building, what's worth doing in the field today. It's the same mechanism by which a bank reminds you about a regular transfer, except the stake here is a harvest rather than a payment.

Second, the person shouldn't have to understand how the system is built. The assistant answers from the data of one specific plot — the crop, the soil, the history of that field — rather than issuing a general recommendation you then have to apply to yourself. Warnings are ranked by urgency and impact instead of arriving as one list you'd have to sort through.

And some of it had to be invented from scratch, because fintech has no equivalent. The app works without a connection and syncs when the network returns. A bank assumes the internet is always there; in rural El Salvador it isn't. That's the case where nothing can be borrowed and the answer has to be found for your own reality.

What the concept doesn't have, and what I'd add today, is the outcome. The system says what needs doing, but shows nowhere whether it was done.

For advice to a farmer about his own field that may not matter. But if an agency is supposed to act on a warning, then next to the warning itself you should be able to see whether the measure was carried out, is being carried out, or the deadline passed and nothing happened. Then the system tells you not only what was known about the risk, but what was done about it.

In closing

What carries over from fintech into public systems is neither the technology nor the budget. It's the way decisions about a system get made: where the rule lives, who takes the first step towards the person, how much effort they have to spend understanding it, and whether the ability to change was built in.

These decisions aren't necessarily cheap to implement: joining up registries and building reliable identification cost money. But making them deliberately at the start is far cheaper than correcting them once the system exists.

And until they are, someone with forty years behind the wheel will be sitting a school exam covering eight years of education in order to qualify for a driving test.