Connectivity monitoring
AI-driven monitoring for every bank connection
Bank APIs break quietly. MVP Payments measures the health of every connection across nine markets at least four times a day and keeps a resident AI agent on every connected bank, one that remembers how that bank behaves, so a change is diagnosed from that history rather than rediscovered from scratch.
Measure, understand, fix
Measure
Every call to every bank records its outcome and latency as it happens. At least four times a day each connection is re-evaluated and classed as healthy, degraded or down. Measured today for sandbox connections; live connections join the same measurement as they go live.
Understand
A change of state opens an entry on the incident timeline, and a daily connection report puts every failing connection in front of our operations team. The bank's AI agent investigates against that bank's API contract and its own journal of past behaviour.
Fix
The agent prepares the diagnosis and the change. An engineer reviews it, tests it against the bank and releases it. The journal is updated, so the next incident at that bank starts from everything already learned.
An agent for every bank, with a memory
The expensive part of maintaining a bank connection is not writing code. It is knowing the bank: that this one rejects a field its own specification calls optional, that one stops reporting status after the customer approves, a third rotates its certificate chain every spring. In most teams that knowledge lives in one engineer's head and leaves when they do.
At MVP Payments it lives with the bank's agent. Every connected bank is covered by a resident AI agent with a standing record of that bank — the current state of the connection, the conventions of its interface, and a dated journal of every investigation. Banks that share one interface share one agent: the Spanish banks on the Redsys hub are one connection to know, and one agent knows it. When the connection degrades, the agent starts from that record instead of from zero.
AI does the reading, the comparing and the remembering, at a scale no team could staff bank by bank. People keep the judgement: every change to a live connection is reviewed and released by an engineer.
What is watched
Every bank connection
Success rate and latency per bank, with health states that change on evidence rather than on a single failed call — measured today for sandbox connections; live connections join the same measurement as they go live.
Certificates
A daily scan of every eIDAS certificate on the platform — including yours — with warnings 30 days and 7 days ahead of expiry. An expired QWAC is the most avoidable outage there is.
Planned maintenance
When a bank announces planned maintenance, an operator can mark it as in maintenance, so its health reads Maintenance rather than Down while the work lasts.
Webhook delivery
Delivery success across the platform is alarmed, every attempt is visible to you, and failed deliveries are retried on a published schedule.
The API itself
Error bursts, queue depths and processing backlogs raise alarms to the operations team, with dashboards drilled before launch rather than after the first incident.
The incident record
Every change of state is written to a timeline — what changed, when, and what was done — so an incident review is a matter of reading, not reconstruction.
Why direct connections make this possible
You can only monitor what you can see. When payments pass through a third-party aggregator, a failing bank looks like a failing aggregator, and the diagnosis belongs to someone else's support queue. Every MVP Payments connection is direct to the bank or its national hub, so we see the bank's actual responses — and can say exactly what changed.
For more on the failure modes, read our guide: why Open Banking connections break, and how to monitor them.
Monitoring questions
- What does "AI-driven connectivity monitoring" actually mean?
- Two layers working together. A measurement layer records the outcome and latency of every call to every bank and re-evaluates each bank’s health at least four times a day. An AI layer covers every connected bank with a resident agent and a long-term record of that bank — its API contract, its quirks and a dated journal of past investigations. Banks that share one interface, such as the Spanish banks on the Redsys hub, share one agent. When a connection degrades, an engineer puts that agent to work: it investigates from the record and prepares the diagnosis and the fix for the engineer to review.
- Does AI make changes to live payment systems on its own?
- No. The AI agents diagnose, explain and propose, and every change to a live connection is reviewed and released by an engineer. This is a deliberate control, not a limitation we are working to remove.
- Where are our certificates kept, and what do the AI agents work from?
- Your certificates and private keys are kept in AWS Secrets Manager, encrypted with AWS KMS keys, with access to them controlled by policy — never in the platform database, in logs or in source control. The agents diagnose from connection telemetry and the bank’s API behaviour: diagnosing a connection needs neither your certificates and keys nor your customers’ personal data.
- What happens when a bank goes down?
- At the next evaluation — at least four times a day — the connection’s health changes state and the change is written to an incident timeline. Our operations team sees every failing sandbox connection in a daily connection report, and a burst of new failures through the API raises an alarm. No provider can make a bank’s own outage disappear; what matters is knowing promptly, knowing why, and keeping customers out of a dead end. A bank marked down stays on the bank list with its health shown, and our operators can withdraw it from the bank picker in one action and restore it once it recovers.
- Why do Open Banking connections need this much attention?
- Because banks change their PSD2 interfaces constantly and rarely announce it well: certificates are rotated, fields become mandatory, authentication journeys are redesigned, and shared banking IT providers ship changes that affect hundreds of institutions on the same day. A connection that worked yesterday can fail today without a line of your code changing.
- Do we need to build our own monitoring on top?
- Not for bank connectivity. You will still want to monitor your own integration — your webhook endpoint and your calls to the API — and the platform helps there too, with visible delivery attempts, scheduled retries and a signed test webhook you can fire from the dashboard.
Stop maintaining bank connections
Keep your engineers on your product. We'll keep the banks connected — and tell you what is happening when they are not.