4 May 2026

Revolut opening a physical store in Barcelona looks like a contradiction until you think about what they're actually solving for.

The app-first model works brilliantly for acquisition. Millions of people download Revolut because it's frictionless and cheap. But frictionless doesn't build the kind of trust that makes someone move their salary into an account, take out a personal loan, or consider it their primary bank. That's a different psychological contract entirely.

This is the problem every digital-first lender and broker in the UK is quietly wrestling with. Conversion at the top of the funnel is largely solved. Deepening the relationship, particularly for higher-value regulated products, is where the model hits its limits. Physical presence is one answer to that, though an expensive one.

What's interesting about the Barcelona location is that Revolut aren't describing it as a branch. It's positioned as an experience space, something closer to an Apple Store than a NatWest. That framing matters because it sidesteps the operational cost of traditional retail banking while still putting humans in the room.

For UK consumer finance leaders, the signal here isn't "open shops." It's that Revolut's 46% revenue growth and expanding loan book still haven't resolved the trust gap that comes with being a relatively young, app-only institution. They're profitable and scaling fast, and they're still investing in physical credibility.

That should prompt some honest reflection for anyone building or running a digital lending operation in this market:

• Where do your customers drop off when the product requires genuine commitment rather than a quick sign-up?
• What does your brand feel like to someone who has never heard of you before the Google ad?

Revolut can afford to experiment with a flagship space in a European city. Most UK fintechs can't. But the underlying question about how you close the trust gap for regulated lending products is one every technology-led credit business needs an answer to, whatever form that answer takes.

The Universal Commerce Protocol is trying to solve a problem that financial services should pay close attention to: who owns the transaction moment when an AI agent is doing the shopping?

The early data from UCP experiments is clear. Merchant-controlled checkout flows convert better than letting the LLM handle everything end-to-end. Agents are good at discovery and comparison. They are not good at being the point of sale. That distinction matters enormously for consumer credit.

Think about how loan origination actually works today. A customer searches, compares, gets pointed somewhere, and then we own the application journey. That model depends on us controlling the moment of intent. If AI agents start handling 'find me a loan and apply for the best one', the question of who owns the checkout layer becomes existential for brokers.

The UCP framing is actually reassuring in one sense. It suggests the industry is converging on a model where merchants, or in our case lenders and brokers, retain control of their own journeys. The agent brings the customer to the door. What happens inside is still ours to design.

But that only holds if we build for it. A standardised protocol for agentic commerce means that firms who have invested in clean APIs, structured product data, and machine-readable eligibility criteria will be the ones agents route traffic to. Firms with PDF rate cards and clunky redirect flows will get bypassed entirely.

The FCA's consumer duty lens adds another layer here. If an AI agent is making credit recommendations on behalf of a customer, accountability for that recommendation needs to sit somewhere. The UCP approach, keeping the merchant in control of the final transaction, at least creates a clear boundary. The agent advises. The lender or broker still executes, discloses, and is responsible.

The question worth sitting with is whether your origination platform is agent-ready, not in a vague future sense, but in terms of whether a well-designed AI could accurately represent your products, check eligibility, and hand off cleanly today.

Rent-splitting products are gaining traction in the US, and you can already see the template being drawn up for a UK version. The pitch is sympathetic: housing costs are crushing people, wages don't align with rent due dates, so here's a bridge. But the moment you charge a fee to access money someone has already earned, you are in the credit business. Calling it a cash flow tool does not change the economics.

The payday lending comparison is not unfair. The original payday lenders also had a sympathetic pitch. They were filling a gap that banks ignored, helping people avoid missed payments and the chaos that followed. The fee structures that look reasonable on a single transaction become brutal when annualised, and the customers most likely to use rent-splitting products are the ones least able to absorb repeated fees.

What concerns me for the UK context is that the FCA spent years cleaning up high-cost short-term credit. The Consumer Duty now requires firms to show that products deliver good outcomes for the customers who actually use them, not just the ones who use them once and never need them again. A rent product targeting people in affordability stress sits right in the middle of that scrutiny.

• The fee-versus-APR framing matters. Regulators and consumers respond differently to a flat fee than to an equivalent APR, and fintech firms know this.
• Rent reporting as a feature is genuinely useful. Helping tenants build credit history from rent payments is a real gap in the UK market. The question is whether that benefit is the product or just the justification for the product.

Any UK firm looking at this space should assume the FCA will view it through a Consumer Duty lens from day one, not as an innovation to be regulated later. The credit rules exist. Wrapping a loan in a different user experience does not create a different regulatory category.

The more interesting question is whether a genuinely low-cost, not-for-profit version of rent smoothing could work in the UK, perhaps through credit unions or employer-linked payroll products. Because the underlying problem is real, even if the current solutions look a lot like the ones we already banned.

Agent Desktop is doing something quietly significant. Instead of having AI agents squint at screenshots and guess where the button is, it reads the OS accessibility tree directly — the same structured data that screen readers use. Structured JSON output, deterministic element references, no pixel matching. For anyone building automation on top of legacy desktop applications, that distinction matters enormously.

In UK consumer finance, we still run a lot of desktop software. Loan origination systems, decisioning tools, case management platforms — plenty of it is thick-client, built in the 2000s, and not going anywhere soon. The usual approach to automating these has been screen scraping or RPA tools that are brittle the moment a window resizes or a UI theme changes. Accessibility tree traversal is fundamentally more stable because it's reading intent, not pixels.

Why This Matters for AI Agents Specifically

The token efficiency angle is underrated. Progressive skeleton traversal means the agent doesn't have to ingest a full UI dump on every action — it navigates the tree incrementally. That's not just cheaper, it's faster and more reliable for multi-step workflows like processing a loan application across three different internal systems.

The two things I'd want any technology leader in financial services to take from this:

• Legacy desktop automation just got meaningfully cheaper to do well, without a full system replacement
• AI agents that interact with applications via structured data are going to outperform vision-based approaches on reliability, and the gap will widen

The FCA's operational resilience requirements push firms toward processes that are auditable and predictable. An automation approach built on deterministic element references fits that framing far better than one that depends on a model correctly interpreting a screenshot.

The question worth asking is how many of your internal processes are still blocked on desktop UI interaction, and whether the assumption that those are too hard to automate is still accurate.