I want to use an analogy that might sound unusual for discussing banking technology, but it perfectly captures what’s happening in the Gulf financial services market. In traditional banking, you catch one fish at a time; one customer, one transaction, one product sale. Banking as a Service is the fishing net that lets you catch many fish at once.
I shared this perspective during our recent Fimple Connects webinar, and I want to elaborate on why I believe Banking as a Service; along with the side-core approach that enables it; represents the most strategic opportunity for GCC financial institutions in 2026 and beyond.
The Competitive Pressure Facing Tier 1 Banks
Let’s start with reality. The banking industry is becoming intensely competitive with the help of technology; AI, advanced analytics, cloud infrastructure, all the capabilities we’ve been discussing. On top of that, fintechs are entering the market and joining the club. There are new players, non-bank financial institutions, all trying to compete with traditional banks on their own ground.
Banks simply can’t stay competitive using their legacy core banking systems. Fintechs and non-bank FIs are generally tech-savvy and super agile organizations. They have limited regulatory adaptation requirements compared to traditional banks. It’s clear that Tier 1 banks must do something to become competitive, and it should start with core banking systems.
The Two Things Banks Need Most
As my fellow panelist Michel clearly mentioned, there are many important metrics for transformation of success. But I want to highlight two that are critical for banks competing in today’s environment:
• Time to Market: The ability to launch new products, features, and services quickly. Fintechs do this in weeks. Traditional banks take months or years. This gap is unsustainable.
• Flexibility and Cost Optimization: The ability to adapt services, scale operations, and optimize the cost of services provided to customers. Legacy systems are expensive to maintain and difficult to change.
All the innovations we discuss; AI, real-time payments, embedded finance, ecosystem partnerships; ultimately happen in the core banking system. That’s where accounts live, where transactions process, where balances update, and where regulatory reporting happens. If your core can’t keep up, none of the innovation matters.
The Core Banking Migration Challenge
For Tier 1 banks, core banking migration typically takes three to five years in the best-case scenario. The success rate of these projects is pretty low, as we all know. We’ve all heard horror stories about migration projects that ran over budget, over timeline, or failed entirely.
Simultaneously, legacy systems offer limited platform capabilities. Everybody these days is trying to do platform business, ecosystem business; integrating their core with other contributors, partnering with fintechs, offering Banking as a Service to non-financial brands. Legacy cores make this extremely difficult and expensive.
Why Full Migration May Not Be the Answer
For Tier 1 banks; large, complex institutions with millions of customers and decades of accumulated data; it may not be very meaningful to consider a full core banking migration unless there is a serious major issue or crisis forcing the change.
Think about what a full migration involves: migrating millions of customer accounts, years of transaction history, complex product configurations, regulatory reporting structures, dozens of integrated systems. The risk is enormous. Business disruption is significant. The opportunity cost; what you can’t do while focusing on migration; is substantial.
This is why I want to talk about the side-core approach as an alternative that delivers many of the benefits of core modernization without the risks and timelines of full replacement.
The Side-Core Approach: Modern Platform Alongside Legacy
Instead of attempting a massive, risky core banking migration, banks can integrate a modern core banking platform into their existing system and conduct modern, platform-based businesses through the modern platform. In this case, the legacy system continues to operate for business-as-usual operations.
In later stages, if the bank chooses, they can use the modern system to replace the whole legacy core banking system. It allows seamless migration over time. But it doesn’t force that decision immediately. You gain the benefits of modern infrastructure while managing risks carefully.
How Side-Core Works in Practice
We use the side-core methodology extensively in our real-world implementations at Fimple, and based on our experience, I don’t believe there will be any issues if the side-core is structured properly. Here’s how it typically works:
Phase 1: New Digital Products on Modern Core
Launch new digital banking products; perhaps a digital-only brand, a Banking as a Service offering, or innovative product lines; on the modern platform. Existing customers and traditional products remain on the legacy core.
Phase 2: Selected Product Migration
As confidence grows, migrate specific product lines to the modern platform. Perhaps start with personal loans, then savings accounts, then business banking products. Each migration is manageable in scope and risk.
Phase 3: Full Replacement (Optional)
Eventually, if the bank chooses, they can complete the migration and retire from the legacy system entirely. But this becomes a business decision, not a technical necessity. The bank maintains optionality.
The Critical Challenge: Single Version of Truth
When I speak from a technological perspective, the challenging part of the side-core approach is modeling a single version of truth. This is the most critical aspect. If you address that topic properly, banks; especially Tier 1 banks and giant institutions; can enjoy having a modern core banking system sitting next to their legacy core.
What do I mean by a single version of truth? When a customer has accounts on two systems, what’s their actual balance across the bank? When a transaction touches these systems, how do you ensure consistency? When generating regulatory reports, how do you consolidate data from both platforms?
This requires sophisticated integration architecture, real-time data synchronization, and clear business rules about which system is authoritative for specific data elements. But it’s a solved problem. At Fimple, we’ve implemented this architecture successfully across multiple institutions, and the patterns are well-established.
Banking as a Service: Two Types of Customers
With the maturing of open finance regulations and the evolution of business models, incumbent banks are pivoting from being direct-to-customer providers to becoming the engine that drives public non-financial brands. This is Banking as a Service, and it represents a fundamental shift in how banks create value.
I believe today banks have two types of customers:
• Financial Customers: Traditional customers who need deposits, loans, derivative products, and other banking services directly from the bank.
• Platform Contributors: Fintechs, Banking as a Service tenant, non-financial brands, and ecosystem partners who use the bank’s infrastructure to deliver financial services to their own customers.
The Win-Win-Win Equation
Banking as a Service creates a win-win-win equation:
Banks Win: They acquire customers they never would have reached directly, earning transaction fees and interest income without customer acquisition costs.
Brand Owners Win: They offer financial services to their customers without becoming licensed banks, increasing engagement and revenue.
Customers Win: They get financial services embedded in the experiences they already use, with less friction and better integration.
This is why I use the fishing analogy. Instead of catching one customer at a time through your branches and marketing, Banking as a Service lets you catch entire customer bases of partner brands all at once.
Integration Capability: The Most Critical Functionality
I want to emphasize something technical but it’s extremely important. From a technical point of view, I would say integration capability and connectivity is the most important and critical functionality for banks. To become competitive and to provide Banking as a Service business in this decade.
Of course, we are going to use some part of functionality from partners or as-a-service providers. That requires integration capability and connectivity capability in a robust way. Today, no vendor or bank itself can develop all banking functionalities from core banking to channels, cards, AML, fraud detection, and AI. These are all big chapters.
Why APIs Are the Foundation
As we all discussed in the webinar, banks need to get services, create platforms, join ecosystems or establish ecosystems, and open their APIs in advance of these technologies and share their SDKs and create their sandboxes.
Technically, if you’re a fintech, you mean you are integrating one system from one system to another. That’s fundamentally what fintech does. And if your system allows you easy, pre-integrated, pre-configured connectivity, it means you have a competitive advantage. It means you have a big chance in competition. It opens doors for innovation and fast time to market and a lot of cost optimization options.
We are experiencing the need for integration capability growing exponentially. Ten or twenty years ago, there were limited connectivity requirements. But now that every bank must behave as a platform and provide Banking as a Service and derivative products, the integration demands are massive and accelerating.
Fimple’s Approach: 9,000+ APIs
I don’t want to do pure advertisements, but I think it’s important to explain our architectural philosophy. At Fimple, we expose every single function; even the most granular functions; as APIs in our core banking system. There are more than 9,000 APIs available.
On top of that, we share our solution development kits with our customers and partners to develop their own intellectual property or create their own Banking as a Service use case. Most importantly, with this approach, it opens the door for extreme use cases in platform banking and Banking as a Service.
Banks focus on business and innovation and enjoy platform developers’ contributions to their business. Instead of banks developing all services for the industry, it’s better to allow platform players to contribute to the bank system. This is the future; banks will convey customer onboarding and financial solutions providing to tenants and Banking as a Service partner, and they will position themselves as platform providers.
The AI Connection: Why APIs Matter Even More
I want to connect this back to the AI discussion from the webinar. When Nikhil asked about AI agents making investment recommendations directly to bank customers, I made a point that might have seemed obvious but is critical:
When an AI agent decides something, it needs to trigger an event. And then it must be an API to trigger that event. Having an API-based system, strong connectivity and integration, accelerates the flexibility of AI agents. It’s not only about investment or deposits or whatever product. AI can do everything, but it needs APIs to actually execute.
AI-Run Banks: Not Science Fiction
I know there are some fintechs trying to establish digital-only, AI-run banks with a limited number of employees. Of course, by regulation, there must be accountable; we’re in a highly regulated industry. But the concept of AI-run banks executing everything through APIs is not far-fetched.
At the end of the day, there must be a modern API-based system to provide holistic service to customers. Whether those services are triggered by human decisions, business rules, or AI agents, the underlying architecture requirement is the same: comprehensive API coverage of all banking functions.
Real-World Implementation: What It Takes
Let me talk practically about what it takes to implement Banking as a Service through a side-core approach:
• Technology Foundation: A modern, cloud-native core banking platform with comprehensive API coverage. This is not negotiable.
•Integration Architecture: Robust synchronization between legacy and modern cores, maintaining a single version of truth.
•Partner Management: Processes for onboarding Banking as a Service tenant, managing their lifecycle, and ensuring compliance.
•Business Model: Clear revenue sharing, risk allocation, and governance frameworks with platform partners.
•Regulatory Alignment: Ensuring all Banking as a Service activities comply with local regulations, which are evolving rapidly in the GCC.
The timeline for implementing this capability? With the right platform and clear business strategy, banks can launch their first Banking as a Service offering within 3-6 months. Compare that to 3-5 years for full core migration.
Conclusion: The Platform Banking Future
I believe we are at an inflection point in banking. The future belongs to banks that think of themselves as platforms. Not just service providers. Banks that understand they have two customer types; financial customers and platform contributors. Banks that embrace Banking as a Service as a core strategy, not a side experiment.
The side-core approach makes this transition possible without the risk and timeline of full core replacement. It gives banks the option to modernize incrementally while delivering value continuously. And it positions banks to capture the massive opportunity in embedded finance and ecosystem banking.
Integration capability and connectivity; having 9,000+ APIs, sharing SDKs, creating sandbox environments. In which this is what allows banks to become the platform that powers the next generation of financial services. Not just for their own customers, but for entire ecosystems of partners and their customers.
That’s the ‘catch many fish at once’ strategy. That’s Banking as a Service. And that’s what GCC banks need to embrace in 2026 to remain competitive in the decade ahead. The technology is ready. The business models are proven. The regulatory frameworks are maturing. The only question is: which banks will move first?
