Connecting to Enterprise Systems: APIs, Events and MCP

Meridian runs about 140 business applications. They talk through an API gateway, an event streaming platform and nightly batch jobs into a data warehouse. Every new system is expected to fit into that landscape using the same patterns, the same security and the same monitoring. An AI assistant gets no special tunnels.

Two facts from earlier sections shape this lesson. The spike measured the Ledger API at 410 milliseconds at p95, too slow to call many times while a customer waits on the phone. And two more AI projects are starting within the year: a complaints triage tool and an assistant for mortgage brokers. Both will need policy search and customer account reads. Built separately, the bank would own three sets of connectors doing the same thing three slightly different ways.

This lesson picks an integration style for each connection, uses events to hide slow work, decides where the Model Context Protocol fits, and produces the integration contract, part A of MER-07.

Three integration styles

The choice follows directly from the freshness table in section 4. Letter figures must be exact at draft time, so the calculator is a synchronous call. Plan history can be a day old, so it arrives by batch. And the account summary sits in between, which is where events earn their place.

Events move slow work out of the wait

When a hardship case is created in Atlas, a staff member typically opens it 38 minutes later, at the median. The design uses those 38 minutes. Atlas publishes an event; a summary worker picks it up, fetches every record, generates the summary and stores it against the case. When the staff member opens the case, the summary is already there.

1{2  "event_id": "evt-9d41c2",3  "type": "hardship.case.opened",4  "schema_version": 2,5  "occurred_at": "2026-05-12T09:14:03Z",6  "case_id": "HC-2026-118733",7  "customer_ref": "C-4471902",8  "products": ["PL", "CARD"],9  "channel": "phone"10}

The event carries references, not customer data. The worker fetches the details itself, under its narrowly scoped identity from section 4, so the event platform never holds a copy of anyone's arrears.

One design detail makes precomputation safe. Figures change during the day, but prose written at 09:14 does not. So the precomputed narrative avoids live figures: it says "two missed payments since March", not "arrears of $1,240". The live figures sit in a separate facts table above the narrative, fetched fresh when the case opens, with an "as of" time. The slow part is precomputed; the part that must be fresh is fetched at the moment it is needed.

What MCP standardises

The Model Context Protocol (MCP) is an open protocol for connecting AI applications to the systems they need. An MCP server exposes three kinds of thing: tools the model can call, resources it can read, and prompt templates. An AI application acts as the client, discovers what a server offers, and calls it using a standard message format. Local servers typically talk over standard input and output; remote servers use HTTP, and the specification defines an authorization approach based on OAuth for that case.

It is worth being exact about what MCP gives you and what it does not.

MCP helps when many AI clients need the same capabilities. Build a policy search server once, and every assistant in the bank that speaks MCP can use it, with the same permissions and logging. It adds little when one fixed workflow calls one API: a direct call is simpler, and the extra layer is one more thing to secure and run.

Meridian's decision follows that line. Policy search and account reads become internal MCP servers, because the complaints and broker projects will reuse them. Letter draft creation stays a direct call from the orchestrator: it has one consumer, it writes, and the bank wants it as tightly held as possible.

Where the pieces sit

The integration landscape has four layers. Each has one job, and each is owned by one team.

1. The Atlas panel — the user interface inside the case system staff already use.
2. The orchestrator — runs the workflows for the three capabilities; owned by the servicing assistant team.
3. The AI gateway — every model call from every assistant passes through it for authentication, routing, quotas, logging and cost metering; owned by the platform team.
4. Tool servers and system APIs — MCP servers for policy search and account reads, direct APIs for the calculator and DocGen, all reaching systems of record through the existing API gateway.

The AI gateway deserves emphasis. Without it, each assistant would hold its own provider keys, its own retry logic and its own logs, and nobody could answer "how much did AI cost the bank last month?" or "which assistants use provider A?" With it, those are single queries.

The integration contract lists every interface, its style, owner, measured performance, authentication and schema version. It is part A of MER-07.