In the first article of this series, I covered the what and the why of using a banking ecosystem as a lens for navigating interconnected complexity. This article is about how to execute.
Before we get into the mechanics, I want to put on the table that a banking ecosystem strategy is not primarily a technology project. It is a leadership project that happens to involve technology.
This matters because it changes who owns it. Technology decisions can be delegated. Leadership decisions about strategy, accountability, and what you are building towards cannot. The institutions I see getting this right have the people at the top deciding what kind of institution they are building, and the technology decisions follow from that.
The banking ecosystem is not a technology project. It is a leadership project that happens to involve technology.
The banking ecosystem you already have
Every lender operating today has an ecosystem; a network of technology, data, partners, processes and people that work together to deliver outcomes for members. The question is whether it is working for you or against you, whether it grew by design or by accumulation, and whether the connections within it are intentional or accidental.
Most of the time, when I look at a lender’s technology environment, I see an ecosystem that nobody planned. A collection of individually sensible decisions that nobody ever looked at as a whole. Systems that work well in isolation and create friction at every handoff. Staff members who have become the connectors, bridging the gaps that the technology was supposed to close.
That is an unintentional banking ecosystem, and most institutions have one.
The goal of this article is to help you become an intentional curator, giving you the questions and the sequence that turns what you already have into something that works with a governing logic.
The three steps to intentionally curating your ecosystem
1. Start with strategy, not technology
The most important place to start might sound slightly ironic in a technology transformation discussion: the first decision is not a technology decision. It is a strategy decision. Because sometimes, technology is not the answer at all.
One of the most common patterns I see is organisations setting out to modernise and moving almost immediately into technology change. Platforms are explored, vendors engaged, and before long the process narrows into procurement. An RFP is launched, requirements are gathered and functional matrices are built and scored. But what is happening is a narrowing of the problem.
Most procurement processes are designed to evaluate individual systems, not ecosystems. They break decisions down into features and functions, when what you are really trying to design is how things work together. If you lead with procurement, you optimise for features. If you lead with strategy, you design for outcomes, and for how your ecosystem needs to work to deliver them.
I worked with one lender who had spent months in a detailed vendor evaluation process before we sat down and asked a simple question: what does a member feel at the moment this works perfectly? They had been so deep in the feature comparison that nobody had anchored the decision to a human outcome. We paused for two weeks, got clear on the answer, and the right vendor became obvious. That pause saved what would likely have been a three-year integration headache.
Before any technology change or procurement process, get precise about the outcome you are trying to create, and how your ecosystem needs to work to deliver it.
‘Faster time to money in the bank’ is an ecosystem outcome. It spans origination, decisioning, data, and disbursement, and it tells you immediately which connections matter. ‘Modern loan origination system’ is a component decision. It tells you almost nothing about whether the whole will work.
Some questions worth working through with your leadership team:
- What friction in our members’ experience do we most want to remove, end to end?
- Where are the breaks today, between systems, teams, or data, that prevent a seamless flow?
- If we designed this as one connected experience, what would need to work together?
- What does our ecosystem need to enable in three years, not just today?
These are ecosystem design questions. In some cases, once you are clear on the outcome, the answer is not new technology at all. It may be simplifying what you already have, or better connecting existing capabilities.
Lead with procurement and you optimise for features. Lead with strategy and you design for outcomes.
2. Audit what you have before you add anything new
Before you add anything new, understand what you already have and how well it connects. Map your current landscape against three questions for each system or vendor:
- What member outcome does this support?
- What does it connect to and what doesn’t it connect to?
- If we were starting from scratch today, would we choose this?
That tells you where your ecosystem strategy needs to fill gaps, and where you have legacy commitments that need an exit plan rather than an extension.
The pattern I see in mutual banks and credit unions navigating this well is that they don’t try to boil the ocean. They identify the member journey with the highest volume and the most friction, map every touchpoint and handoff in that chain, and start there. Then expand.
3. Think about banking technology accountability: own versus access
Once you have clarity on strategy and an honest picture of your current state, the work becomes intentional.
Now the questions to ask are: what do you own, and what do you access? And who do you build it with?
What do you own, and what do you access?
This is the accountability question, and it is broader than technology. It is about where responsibility sits for the connections, the integrations, and the ongoing work of keeping your ecosystem coherent and current.
Some institutions own their core capabilities outright; proprietary technology, proprietary data models, proprietary integrations. This makes sense when the capability is genuinely differentiating. If your credit risk model for a specific member segment — farmers, self-employed professionals, first home buyers — is genuinely better than anything on the market, that is worth holding close. But owning it means owning the full ecosystem responsibility: the architecture, the connections, the cost of keeping it all current. Nobody else will do that work for you.
This is also true when you tap into the growing network of fintech partnerships available across the Australian and global market. Open banking rails, embedded lending solutions, shared fraud detection networks, the fintech community has done impressive work here. These players are well-connected, fast-moving, and actively filling gaps that traditional vendors have been slow to address. They are worth engaging with and worth building into your ecosystem. The trade-off is ownership: plugging in still requires your institution to do the stitching. The integrations, the relationship management, the work of keeping those connections current as both sides evolve, that accountability sits with you, and it needs to be properly resourced in time, budget, and capability.
The alternative is to access an ecosystem that someone else has already curated, accessing a SaaS banking platform rather than one you own and maintain. A digital banking platform serving the Australian market is a good example. Your members need it to be fast, seamless, and reliable. But what they actually want is your values, your bond, the community you create. The technology is the vehicle. Rather than owning and maintaining that vehicle yourself, you access one that already comes with an ecosystem of connected services built around it.
What you must demand is that the platform genuinely delivers on that promise. This is where many institutions get caught out. They evaluate a loan origination system on features, price, and the quality of the demo. What they do not always evaluate is the depth and integrity of the ecosystem underneath it.
A distinction worth making because marketing language tends to obscure it, is that not all cloud-native platforms are the same. There is a meaningful difference between a cloud-native, multi-tenanted SaaS platform where the architecture is shared, and a customised cloud build, where a vendor spins up a dedicated instance for your institution.
Both might be called cloud-native, but the experience is quite different. With a true multi-tenanted platform, when the vendor improves an integration, adds a connected service, or extends the ecosystem, every client benefits automatically. The interoperability is architectural. You grow as the platform grows. With a customised instance, you may have more control over specific configurations, and for some institutions with genuinely unique requirements, that can be the right trade-off. But you are taking on a different kind of ongoing accountability. That instance needs dedicated support to stay current, and the broader ecosystem the vendor has built may not be as accessible to you. Customised cloud builds move towards legacy faster than people expect, and when they do, the cost of remediation falls squarely on you.
When you access a platform, you are accessing an ecosystem and inheriting its philosophy about connectivity. Before you commit:
- Who governs this platform and does their incentive structure align with mine?
- What happens to my member data, and who controls it?
- Is this a true multi-tenanted SaaS platform, or a customised build, and what does that mean for how the ecosystem evolves?
- Can I exit if my needs change, or does this become a dependency I cannot undo?
- Is this partner building towards the same future my members will need, or towards their own growth metrics?
Technology relationships in financial services are long. The vendor who wins your business in 2026 is likely to still be in your environment in 2031. That deserves scrutiny that goes well beyond the feature set.
Who do you build it with?
An ecosystem is only as strong as the relationships within it, and the institutions that get this right treat their technology partnerships as genuinely bilateral relationships, not procurement transactions.
They show up as active partners. They share honest feedback. They engage with vendor roadmaps and flag what is not working before it becomes a problem. And because they do, their technology partners invest back in them. Platform features get shaped around their real use cases. Integrations get prioritised. When something breaks, it gets fixed faster because there is a relationship, not just a contract.
I have seen technically superior platforms fail in mutual bank environments because the vendor’s culture was wrong, optimised for their own growth metrics, not their clients’ member outcomes. And I have seen mid-tier platforms perform brilliantly because the relationship was genuinely collaborative. In a long technology relationship, culture travels further than capability.
Why now is mutual banking’s moment to lead
The financial services industry is in the middle of a transition. The decisions being made now about accountability, about partners, about culture, will determine which institutions are well-positioned in five years and which are playing catch-up.
Mutual banks and credit unions have everything they need to lead in this environment; the values, the member relationships, and the cooperative instinct. The track record of doing hard things in the service of people, not just profit.
The institutions that step into the role of intentional ecosystem architect now, making clear leadership decisions about strategy, accountability, and partnership, will be the ones whose members feel the difference. The rest will spend the next five years catching up to decisions they could have made today.
The banking ecosystem is not a technology project, it is a leadership project that happens to involve technology. And leadership is what credit unions and mutual banking has always done well.
If you are ready to explore what an intentional ecosystem strategy looks like for your institution, whether that means auditing what you have, stress-testing a vendor decision, or thinking through the ‘own versus access’ question for your specific context, get in touch here.