You Own the Airport

By Robert Jakech, Co-founder of FITER

Why Open Source Core Banking Gives You Control That Monoliths and SaaS Never Will

Think about an airport. Not the experience of passing through one, but the structure itself. The building. The infrastructure. The way it works.

An airport is a platform. Inside it: check-in counters, security screening, immigration booths, departure lounges, food courts, shops, boarding gates. Facing outward: runways, taxiing zones, gates where aircraft dock, baggage reclaim carousels, the kiosk space near arrivals where car rental companies set up. Each part serves a distinct purpose. Each can be operated by a different provider. And yet they all function within one coherent structure.

This is the metaphor for understanding core banking architecture. And more specifically, it is the metaphor that explains why the choice between open source, closed-loop monolith, and SaaS is not purely a technical decision. It is a question of ownership.

The Airport as Any Core Banking System

Before we get to what separates open source from everything else, we need to be precise about what the airport represents in this metaphor.

The airport is the core banking system. Any core banking system. What goes on inside it are the functional modules: savings accounts, loan origination, the general ledger, client management, fixed deposits, transaction processing. These are the rooms and areas of the airport. The check-in hall. The security checkpoint. The departure lounge. The immigration counter. The food court. Each is a functional space within the structure, and each handles a specific part of what the system does.

Check-in Area Check-in is where every journey begins. In core banking, this is client onboarding. Identity, registration, account opening.

These internal modules are not optional extras. They come with the system. When you build on Apache Fineract, these are the rooms inside your building. They are where the core business of banking happens, and they are part of the base structure from day one.

Food Court One space, many choices. This is the savings module. Multiple products configured with different rules, rates, and limits, all running on shared infrastructure.

The Orchestration Layer

Now look at the parts of the airport that face outward. The runways. The gates where aircraft dock. The arrivals hall. The baggage carousels. The dedicated space near the exit where car rental companies place their kiosks.

These are not passenger areas. They are connection points. The places where the airport receives the outside world and sends it back out again.

Airport: with many fixtures and infrastructure

In core banking terms, this is the orchestration layer. It sits around the core and provides structured, well-defined points where external services can connect. A runway does not belong to any one airline. Gate 14 is not permanently assigned to any carrier. The baggage carousel processes whatever luggage comes through. The kiosk space is infrastructure that any qualifying operator can occupy.

Baggage Carousel Every bag sorted to the right owner, every time. This is the general ledger. Journal entries posted, classified, and balanced across every account.

These connection points are designed to be flexible. In banking, they are the integration endpoints for payment gateways, card providers, AML services, mobile banking applications, service buses, aggregators, switches, and any other third-party service the institution needs. The orchestration layer is built around the core, and it determines how easily you can connect, swap, and disconnect the services that plug into it.

External Services: The Airlines and the Tenants

The airlines that land at the airport do not own the runway. The Starbucks near Gate 22 does not own the food court. The car rental company at the arrivals exit does not own the kiosk space.

They are tenants. Service providers who operate within infrastructure they do not control. The airport assigns them their place, defines what they can do there, and decides how long they stay.

In banking, these are the external services: payment gateways, KYC providers, card networks, fraud detection engines, mobile wallet integrations, notification platforms. They connect through the orchestration layer and deliver a service. The airport keeps running regardless of which tenant is present at any given time. If one airline stops flying, another takes its gate. If your payment gateway underperforms, you disconnect it and connect a new one.

The question is not whether the airport can accommodate different services. Any airport can. The question is who controls the airport.

Open Source: You Own the Airport

With open source core banking, specifically Apache Fineract as implemented by FITER, you own the airport. The code is yours. The infrastructure is yours. The blueprints are yours.

Shops Specialised offerings that deepen the experience. These are your fixed deposits, recurring deposits, and investment products. Each with its own terms, serving different customers.

You can rearrange the interior. Move the check-in counters. Expand the food court. Build a new departure lounge. Redesign how passengers flow through security. You can add gates, extend the terminal, reconfigure the baggage system, and decide which car rental companies get kiosk space and on what terms.

Security Scanning Nothing passes through unchecked. This is the maker-checker workflow. Every transaction is inspected, approved, and logged before it clears.

You can do all of this because the source code is open and the implementation belongs to you. There is no vendor standing between you and your own system. Want to add a new product? Build a new room. Want to change how transactions route? Redesign the corridor. Want to switch payment processors? Reassign the gate. None of this requires permission from anyone outside your own organisation.

This is ownership in the practical sense. You control the system, you set the roadmap, and you make the decisions.

The Monolith: A Building You Cannot Rearrange

Now consider the closed-loop monolithic alternative, typified by systems like Flexcube. The vendor hands you an airport. Check-in, security, lounges, gates, runways. It is all there, and it is all pre-built.

But you do not own it. You lease it.

You cannot move the check-in counters. You cannot add a new shop without going through the vendor, on their timeline, with their contractors. You cannot remove the car rental kiosk even if nobody uses it. The gates serve the airlines the vendor has agreements with, not necessarily the ones you want.

If you need to switch payment gateways, the answer is usually no. The integration is hardwired into parts of the structure you cannot access. Changing it means rewriting code you do not have. The floor plan is fixed. The walls do not move.

For some institutions, that predictability works well enough. But the moment your needs diverge from what the vendor originally designed for, you feel those walls.

SaaS: Someone Else’s Airport Entirely

The SaaS model, typified by platforms like Mambu, takes it a step further. You are not leasing a building. You are buying a seat on someone else’s plane, inside someone else’s airport.

The provider operates the entire structure: core, integrations, infrastructure, updates, security. You get a login and you get access to whatever the platform offers.

What you do not get is control.

You cannot change the internal architecture. You cannot add a module the provider has not built. If they deprecate something you rely on, you adapt or you leave. If their system goes down, yours goes down with it. If their roadmap moves in a different direction, you wait.

For early-stage institutions, SaaS can make sense. The speed of deployment and low upfront cost are real advantages. But as an institution grows, and as its products become more specific to its market and regulatory environment, the lack of control compounds. What started as a convenient arrangement becomes a structural constraint.

The Question Is Simple

When evaluating core banking systems, the technical comparisons matter. Throughput, latency, module coverage, API design. All of it matters.

But beneath all of that is a more fundamental question.

Do you want to own the airport? Or do you want to be a tenant in someone else’s building, hoping they never change the locks

About the Author

Robert Jakech is Co-founder and CTO of FITER. He has decades of experience in the fintech community, working with stakeholders across the industry, speaking at open source conferences, and engaging with hundreds of financial institutions, neobanks, and digital banks that have embraced open source technology. Robert has been instrumental in helping these institutions implement Apache Fineract across a wide variety of use cases, from microfinance and savings cooperatives to full-service digital banks operating across multiple markets.

FITER is the number one Apache Fineract implementer in the world, with over 100 implementations across more than 25 countries on five continents.