Most financial institutions have spent years building API infrastructure. Few have built it to support what comes next.
At LEAP 2026, Mark Boyd, founder of Platformable, laid out the problem clearly: the adoption gap in Open Banking and AI isn’t a technology problem. It’s a context problem.
Banks are deploying APIs without a structured understanding of:
- Who they serve
- What markets they operate in, or
- What their organizations are actually capable of delivering.
When AI enters that environment, the cracks become craters.
Boyd’s solution is a context-first approach to digital infrastructure, one that gives humans a governing role over AI outcomes and enables intelligent agents to navigate uncertainty without breaking down.
The results, when done well, are significant.
- ABN AMRO used this approach to spin up a digital bank for teenagers in under a year.
- Klarna built an agentic product protocol API that creates value across its entire client ecosystem.
Watch Boyd’s full session here, or read on for the key takeaways.
The problem: AI needs more than APIs
Smart finance today spans Open Banking, Open Finance, stablecoins, embedded finance, and agentic commerce. All of it runs on API infrastructure. But for agentic AI to function on that foundation, it needs to understand intent, not just execute instructions.
Without that understanding, organizations run into two compounding problems.
- API drift, where what gets built no longer matches what was intended.
- API sprawl, where APIs multiply faster than anyone can track or govern them.
Context engineering is Boyd’s answer. It’s the practice of describing intent in enough depth that AI systems can act on it reliably, even when things go wrong. That means documenting use cases, operational environments, and organizational capabilities in a structured way that both humans and agents can navigate.
Five types of context that matter
Boyd breaks context into five layers, each one essential to building infrastructure that actually delivers value.
User context is about deeply understanding who you’re building for.
Boyd uses Gen Z as an example: ages 13 to 28, entering banking for the first time, with strong fintech preferences, a rent-not-own mindset, and expectations around instant payments and round-up savings. ABN AMRO’s teenage digital bank succeeded because the institution had already done this work at the infrastructure level.
Corporate banking has its own user context: enterprises increasingly want direct integration between their bank accounts and ERP systems, enabling real-time cash flow visibility, optimized payments, and cross-border transaction management.
Global context covers the macro forces shaping where and how banks can operate.
Data sovereignty regulations in France and Germany now require consumer and business finance data to be stored on in-country servers. AI regulation is converging with Open Banking compliance across markets from the UK to Australia to Singapore.
Meanwhile, the way customers find and engage with financial services is shifting, as search traffic drops and online communities fragment across WhatsApp, Discord, and Signal. Ecosystem-led growth and partnership strategies are becoming a primary customer acquisition model.
Local and regional context means staying current on the regulatory milestones specific to each market you operate in.
Sixty-eight countries now have Open Banking regulations in place, with 21 more moving in that direction. Cross-border players are managing a constantly shifting set of local requirements alongside AI regulation, instant payment rules, and regional standards like the Berlin Group framework and Financial Data Exchange (FDX). Interoperability is not optional in this environment, and API aggregators are filling standards gaps in the meantime.
Organizational context is where many adoption efforts quietly fail.
A top-down mandate for API governance doesn’t work in a federated organization where business lines operate independently. Boyd recommends mapping accountability gaps using RACI frameworks to surface where API and AI workflows fall through the cracks. He also suggests framing adoption conversations around what each department actually cares about: revenue, cost savings, equity, or operational efficiency. The Banking Industry Architecture Network (BIAN)’s capabilities model is a useful tool for mapping business capabilities to value streams, making it easier to track intent across the organization.
Digital and infrastructure context ties it all together.
Boyd recommends using Arazzo workflows to document how APIs combine to serve specific use cases, and notes these are also useful for MCP descriptions and AI-readable documentation like Agents.MD and llm.txt. ABN AMRO’s 2028 corporate roadmap offers a concrete example of this vision: decommissioning legacy applications, increasing API coverage, and moving toward modular, composable instances that spin up for a task and retire when done.
Klarna offers the clearest commercial example of this in action. It used AI to build an agentic product protocol API, a deliberately low-risk, high-value starting point. Rather than pointing AI at customers first, Klarna built product catalogs that allow its clients to surface relevant products and services for their own customers. The result creates value at every layer of the ecosystem: Klarna’s business model strengthens, clients get a better toolset, and end users get a more relevant experience. Klarna reinforced this with ecosystem-specific documentation and tailored customer journeys for each partner, effectively turning its API into an interoperability toolkit. It’s a useful model for any institution thinking about where to start with agentic AI.
FinOps: Where infrastructure meets business value
Boyd’s framework doesn’t stop at architecture. It connects directly to cost management through FinOps modelling, using the FinOps Foundation’s AI frameworks as a starting point.
There are three components.
- Infrastructure capital expenditure, which is often ring-fenced separately for AI workloads right now.
- Operational cost, where API metrics become a direct input to quantifying business savings.
- Value realization, where AI usage is mapped to revenue outcomes and business goals.
Getting this right turns infrastructure decisions into business cases, which is what earns cross-functional buy-in.
Three steps to get started
Boyd closes with practical guidance for organizations ready to move:
- Map your context first. Use an ecosystem model to build a complete picture before making infrastructure decisions.
- Don’t skip business capabilities mapping and API governance. They might feel boring but these are important foundations that will enable acceleration and scalability.
- Start AI with low-risk, high-value use cases rather than customer-facing initiatives. FinOps is the right first target. Build a catalog of AI use cases from there, and use sandboxes and synthetic data wherever possible
Want further tips? Then speak to Tyk for tailored insights and advice.
Frequently asked questions
What is context-first API infrastructure in Open Banking? Context-first API infrastructure is an approach where banks document the intent behind their APIs before building them. That means mapping user needs, regulatory environments, organizational capabilities, and technical workflows so that both humans and AI agents can act on them reliably. Without this foundation, banks end up with API drift (what gets built no longer matches what was intended) and API sprawl (more APIs than anyone can govern).
What is context engineering and why does it matter for agentic AI? Context engineering is the practice of describing intent in enough depth that AI systems can execute tasks reliably, even when they encounter errors or unexpected inputs. As financial services move toward agentic AI, where systems act autonomously on behalf of users, AI needs to understand not just instructions but the business environment those instructions operate within. Context engineering provides that foundation.
How should banks get started with agentic AI? Boyd recommends starting with low-risk, high-value internal use cases rather than customer-facing applications. FinOps is the most practical first target: using API metrics to quantify infrastructure costs and identify savings. From there, banks can build a catalog of AI use cases, test in sandboxes with synthetic data, and scale from a position of documented intent rather than reactive deployment.
What is API drift and how do banks avoid it? API drift happens when the APIs an organization builds no longer match the original business intent behind them. It’s common in fast-moving environments where development outpaces governance. The solution is context-first API governance: documenting use cases, mapping business capabilities, and using frameworks like Arazzo workflows to track how APIs serve specific outcomes over time.
What Open Banking standards should financial institutions be building with? It depends on the market. In the US, FDX is the primary standard. In Europe, the Berlin Group framework applies. Sixty-eight countries now have Open Banking regulations in place, with 21 more moving in that direction. For cross-border institutions, API aggregators are currently filling interoperability gaps while global standards continue to develop. Regardless of region, Boyd’s core recommendation is the same: build with interoperability as a requirement, not an afterthought.
