The supplier a bank cannot leave is usually its integrator, not its cloud
Boards ask about concentration in cloud providers, and they should. In a mid-sized bank, though, the harder dependency often sits with the systems integrator whose staff alone understand how the channels reach the core. Keep design authority on the bank's own payroll before negotiating anything else.
When boards discuss supplier concentration in banking, the conversation usually turns quickly to cloud providers. That is understandable. A small number of global firms host a growing share of the industry's systems, and supervisors in many markets, ours included, expect banks to show that they understand the risk. My position is that in a mid-sized bank the harder dependency usually sits elsewhere: with the systems integrator whose engineers are the only people who understand how the bank's channels connect to its core. A bank should keep design authority, meaning the people who decide how its systems fit together and who can change that fit, on its own payroll. Until it does, every other supplier negotiation is weaker than it looks.
Where the dependency actually sits
In 2020 Marrowgate Technologies received about ₱1.9 billion of our ₱3.0 billion change budget. That figure appeared in our board papers as a cost concentration, and it prompted the usual responses: benchmarking, a tougher negotiation, a review of day rates. What the papers did not show was more serious. Three Marrowgate architects were the only people anywhere who understood the integration layer through which our app, ATMs and card systems reached the mainframe. Every significant project queued for them. Had Marrowgate moved them to another client, which the contract permitted, nobody at Talampas could have safely changed how a customer's payment reached the ledger.
A spend figure measures what a bank pays. It does not measure what the bank could not do without the supplier, or how long rebuilding that capability would take. Those are the questions that matter in a crisis or a dispute, and they are hard to answer from procurement data. I now ask a different question of each major supplier: if this firm stopped working for us next month, which changes could we no longer make, and who inside the bank could make them?
When Marrowgate offered a five-year exclusive renewal with a 9% rate reduction in 2021, our procurement team recommended accepting it. On price, they were right. We declined, split the work into three lots and paid about ₱310 million in transition costs. Delivery slowed by roughly a fifth in the first half of 2022, and that May a failed integration release took our ATMs and cards down for two hours and ten minutes on a Saturday. I do not want to understate those costs. By 2024 Marrowgate's share of change spend was 37%, and nine people, most of them our own employees, could change the integration layer that three had once held.
Design authority stays on the payroll
The lesson I draw concerns where knowledge sits, not any particular supplier. Marrowgate did good work for us for many years, and still does. The failure was ours. We had allowed the understanding of how our own bank fitted together to accumulate in another firm's staff, because hiring that understanding was slower and dearer than renting it.
Design authority, as I use the term, is a small group of architects and senior engineers who own the bank's integration patterns, approve how new systems connect to old ones and can explain any significant interface without calling a supplier. At Talampas it began with twelve people in 2021 and now sits within an in-house engineering team of fifty-two. It does not build most of our systems; suppliers still do. But no supplier now holds knowledge we cannot reproduce, and every contract carries documentation and handover obligations that the design authority checks before each payment milestone.
This costs money that is easy to cut. Engineers who understand a bank's integration layer are scarce in Manila and attractive to every supplier and competitor. When budgets tighten, an internal architecture team looks like overhead beside a supplier invoice for delivered features. I have defended it each year by showing the board what the alternative cost us in 2021, and by reporting, for each critical interface, how many people inside the bank can change it. That count has become the most useful single line in our supplier reporting.
What I tell the board about cloud
None of this makes cloud concentration unimportant. We have moved our mobile channel, fraud analytics and development tooling to cloud services, while the deposit ledger remains in our own data centres. The central bank's technology-risk and outsourcing expectations are clear that moving a service to a provider does not move accountability: the board and senior management remain responsible, due diligence is expected, and a bank should know how it would exit and be able to give examiners access. I agree with all of that.
For each cloud service, the board IT steering committee receives a one-page record: what runs there, what customer data is held outside the country, how we would leave, how long leaving would take and who inside the bank could lead the exit. The last item is the one I care about most, and it is the same question I ask about integrators. An exit plan written by the provider and executed by the provider's partners is not really an exit plan.
There is a temptation, in board discussions of cloud, to treat the provider as the risk and the bank's own capability as a given. In my experience the reverse is closer to the truth. Large cloud providers are usually more resilient than the data centres they replace. What fails is the bank's understanding of how its services are assembled on top of them, and that understanding is easy to outsource without anyone noticing.
The two risks are also linked. When we moved fraud analytics to a cloud platform, the provider offered its own partner to build the pipelines. We used that partner for part of the work, but our design authority owned the data model and the interfaces, and two of our engineers now hold the knowledge that would let us rebuild the service elsewhere. Without that rule we would simply have swapped one integrator for another, with a cloud bill attached.
My suggestion to other boards is to ask management two questions at the next supplier review. For each critical system, how many people on our own payroll could change how it connects to the rest of the bank? And which supplier's departure would leave that number at zero? The answers will reveal more about concentration than any spend chart.