Financial services are entering a new phase, one where AI doesn’t just analyze data, but securely interacts with regulated financial infrastructure in real time.  

At Infinum, we are fully aware of the challenges and considerations involved in connecting a ChatGPT App to live banking data. Using Model Context Protocol (MCP) and PSD2 open banking APIs, we have enabled users to authenticate once and then query balances, transactions, and spending summaries in a conversational manner, all without leaving ChatGPT. 

This post will walk you through the architecture, how authorization works, and how users can retrieve live banking data directly inside Chat GPT. We’re also going to talk about the design decisions and limitations that came up when building it. 

A Glance at the Architecture 

The ChatGPT App configuration is deliberately minimal: a public MCP server URL and an OAuth enabled flag. Everything else, auth logic, access control, data scoping, lives server-side in the MCP layer. That separation is a feature, not an oversight, and it shapes how we handle authentication and permissions. 

OAuth and PSD2 Scopes

This layer is critical for protecting access to sensitive financial data. To achieve this, we use OAuth 2.1, the industry standard authorization protocol. Once the user successfully authenticates and grants explicit consent, the provider issues a secure access token. This token allows our system to retrieve only the permitted banking data (such as balances or transactions) through the provider’s APIs. 

When initiating the OAuth flow, we explicitly declare which PSD2 permission scopes the token should cover. Depending on the action the user want to make In our implementation, we request only three: 

Narrower scopes mean a cleaner consent screen and a smaller blast radius if a token is compromised. This maps directly to the principle of least privilege: request only what the feature actually needs. 

90-day re-authentication (PSD2 requirement) 

PSD2 mandates re-authentication every 90 days. Our implementation satisfies this by design: tokens are short-lived and tied to individual sessions. Users re-authenticate each time they start a new session, which in practice happens far more frequently than every 90 days. No special tracking or forced re-auth flow is needed. 

What happens when a user withholds a scope? Currently, the initial token grants all three read scopes together. We don’t issue per-resource tokens. If a scope is not granted, we simply don’t return that data. We don’t surface an error or attempt to call the API without permission. 

Taken together, this approach mirrors the security model used by many mobile banking and FinTech applications, where OAuth based authorization ensures that access is controlled, permission-based, and revocable at any time. 

But once a user is authenticated, how does ChatGPT know which banking actions it can perform on their behalf? 

That’s where the MCP server comes into play. 

MCP Server: Tool Definitions as the Security Boundary

This is where access control lives. Every capability the model has is an explicitly defined tool. There is no freeform API access, if a tool for initiating payments doesn’t exist, the model has no mechanism to trigger one. The tool definitions are the boundary. 

We’ve specified a list of actions and what each action does: 

The Auth Check Gate

The `auth-check` tool acts as a gate for all other tools. Before any data-fetching action is invoked, the model is instructed to first verify that the user has an active, valid session. This dependency is structural: in the tool descriptions themselves, we explicitly specify that balance, transaction, and account tools should not be called unless the auth-check has returned a confirmed authenticated state. The model cannot bypass this because it has no alternative path to the data.

The Audit Trail

Every tool invocation is logged at the MCP server level, producing a structured audit trail.  

Each log entry captures: 

This gives us a complete operational record for debugging and figuring out if the model is calling the right tools. 

The UI Components

UI components are served through the MCP layer and have no independent access to provider APIs. UI components are served through the MCP layer and have no independent access to provider APIs. When a component needs user-specific data (a balance card, a transaction list), it receives a pre-fetched payload passed through the tool response that triggered it. The JWT token and granted scopes are held server-side and never forwarded to the component directly. The component renders only what the MCP server explicitly provides.  

The entire implementation is based on the new Apps SDK.

A note on Infobip’s model

The same MCP pattern applies to Infobip’s communication infrastructure, SMS, WhatsApp, RCS, Voice, Viber, 2FA. Each channel is exposed as a dedicated MCP tool with its own scope and constraints. The enforcement mechanism is identical: tools as the boundary, least-privilege by design. 

Provider Agnosticism

One decision worth calling out explicitly: the architecture is Open Banking provider-agnostic.  

Without an Open Banking API provider the system cannot function. The whole idea is dependent on the providers. All banking information is provided by them, so we need to connect with such a provider and extract the information in a secure way. 

The MCP server communicates with the provider through a standardized PSD2 interface, which means the underlying provider can be swapped without changes to the MCP layer or the ChatGPT App. 

In practice, providers vary in how faithfully they implement the PSD2 spec, so some adaptation at the integration layer is expected. But the core architecture has no single-provider dependency baked in. 

Dynamic Client Registration (DCR) 

Since we integrate through a single Open Banking API provider rather than directly with individual bank authorization servers, DCR is handled at the provider level. It’s not something our architecture needs to address directly. 

LLM Limitations Worth Knowing 

With the architecture in place, there are a few model-level constraints that affect how far the current implementation can stretch. 

Rapidly changing financial data (exchange rates, stock prices)  

The model doesn’t have live financial context by default. The correct approach is a dedicated MCP tool that fetches current data before any function that needs it. We haven’t implemented this yet, but the pattern is straightforward: add a get-market-context tool and instruct the model to call it first. 

Local regulation and terminology outside the training set 

For the use cases this app targets — consumer-facing, non-specialist — the base model’s training data has been sufficient. For regulated or jurisdiction-specific deployments, a RAG layer or a context-injection tool would be the right extension point. 

Keeping Financial Data Out of the LLM Context 

Beyond model limitations, there’s a broader question about data handling that’s directly relevant to PSD2 compliance. 

We control what we can on our side: MCP tools return lean, structured payloads (not raw API objects), and no financial data is stored server-side beyond the lifetime of the request. What happens inside OpenAI’s platform is governed by their data policies, and those policies vary by account type. 

For any financial use case operating under PSD2, users should access the app through a ChatGPT Team or Enterprise account, or at minimum disable training in their data controls settings. 

The End-Result: Conversational Open Banking 

Once a user connects their bank account through the OAuth flow, they can interact with their financial data conversationally inside ChatGPT. 

Instead of opening a banking app and navigating through menus, the user can ask: 

The experience feels like messaging a financial assistant who already understands your question and knows where to look. Behind the scenes, everything remains secure and permission-based, but from the user’s perspective, it’s effortless. 

This article was originally published on the Infobip Developer Blog. Learn more about Infinum and Infobip’s integration partnership.

For the past two years, most organizations have been consumed by a single, driving question: “How can we leverage AI in our business?” But as the market matures, the more critical question becomes: “How can we provide AI with the live context needed to function effectively?”

The “Static Context” Trap

There is a typical scenario that an organization lives through in its pursuit of AI utility. In an effort to deliver immediate value, an organization feeds an LLM its Confluence pages and a collection of internal PDFs. The model answers questions accurately, and the implementation feels seamless. Stakeholders are satisfied with the newfound efficiency. The results are an instant success.

However, the organization inevitably hits a wall as the reality of a moving business catches up with the static data of the past. If context is not retrieved dynamically, the AI cannot participate in a workflow – it can only summarize old news. This creates a strategic ceiling.

Most AI pilots reach a fatal point when they are too disconnected from the live environment to be trusted with business operations. Failure then spills into customer experience, internal operations, and revenue-impacting workflows. Eventually, it becomes clear that the issue is not the model’s intelligence but a lack of a live connection to the company.

That’s why the next wave of AI-enabled businesses will be defined by Model Context Protocols (MCP). This critical infrastructure bridges the gap between static reasoning and real-time business reality.

Enter the Model Context Protocol (MCP)

From a business perspective, model context is not about tokens or prompts. It is about ensuring that AI systems:

This is the foundation of how we approach AI and data engineering — every system we build is designed from the start with defined access boundaries, governance, and real-time data integration.

From “Advice” to “Action”

The transition from static data to dynamic protocols changes the utility of AI. This is best illustrated by an example emphasizing the difference between an assistant that remembers information and an assistant that knows how to fetch it.

The Static Way: Relying on Memory

In a static approach, an organization uploads thousands of PDFs, product manuals, and pricing sheets to a vector database. The AI is then prompted to use these documents to answer questions. However, as documents become outdated and regulations evolve, the system begins to fail.

Consider a customer asking for the current cancellation policy for an enterprise account in Germany. A static AI might reference a 2024 PDF and confidently provide an outdated answer. It has no way to verify whether that policy is still valid or even applies to that specific region. The customer ends up frustrated and exits the chat. 

This forces a human agent to intervene to fix the mistake manually. In this model, the engineering team’s daily workload is consumed by the repetitive task of feeding the model new data snapshots instead of building new capabilities.

This is one of the core pain points in AI chatbot development — we’ve documented how knowledge base staleness and hallucination undermine even well-scoped chatbot projects.

The MCP Way: Relying on Access

In the MCP Way, the business defines a standardized context layer. This protocol specifies exactly which tools the model can use and which data sources it can access in real time. Instead of relying on a folder of old files, the AI operates like a user with a live internet connection.

When asked about the same German cancellation policy, the AI identifies the region and customer type. It then uses the protocol to hit the live policy API and the subscription store. It recognizes the most recent “instant” policy tag and confirms the customer’s eligibility. Because it has a secure communication layer, it can provide more than just a text response. It triggers the cancellation through Infobip MCP Servers or another messaging tool.

This is the jump from an AI that talks to an AI that operates, ensuring that every action is grounded in verified, real-time data. This shift is at the heart of AI automation — moving beyond smart responses to systems that execute workflows end-to-end. For concrete examples of what this looks like inside enterprise systems, see our work on AI-powered knowledge hubs across insurance, tech, and procurement.

The Strategic Shift in Business Architecture

The value of structured model context extends beyond improving answers. When context is delivered via a Model Context Protocol, AI systems shift from isolated responders to reliable participants in business processes that operate within defined boundaries, using approved data and actions. Building these systems from the ground up is what our AI agent development services are designed for — from prototype to production in a structured, risk-managed engagement.

Most importantly, MCPs enable this without hard-coding logic into every application. Whether an organization is building internal tools or integrating with the ChatGPT Apps SDK, a robust protocol ensures engineers do not have to rebuild the connection between the brain and the data each time. The organization builds the protocol once, and the AI scales with the business.

The No-Brainer Approach

The industry has spent two years fixating on the LLM’s brain while neglecting the nervous system required to connect it to the enterprise. Model Context Protocols are the neurons that bridge this gap.

As models commoditize, competitive advantage shifts from raw intelligence to architecture. The winners will not be defined by the size of their LLM budget, but by the sophistication of the nervous system that gives their AI the agency to act. If you’re ready to build that nervous system, our custom AI solutions team designs production-grade AI architectures built around your workflows and data.