In today’s financial services landscape, more institutions than ever are holding a banking licence and preparing to serve their first customer. Across the Gulf, Egypt, Türkiye and Central Asia, regulators keep authorising new digital banks, participation banks, and finance companies. Each arrives at the same moment: the licence is granted, the capital is committed, the board has announced a date, and the countdown begins. 

That countdown is rarely lost on the things institutions examine most closely during vendor selection. In this blog post, we will look at where those months actually go, and at the two platform properties that decide whether your date holds. 

Where the Months Actually Go 

Ask a newly licensed institution what its teams are working on six months in, and core banking installation is rarely the answer. Three things consume the calendar: 

1. Defining and Redefining Products: pricing, tiers, profit or interest treatment, charges, and accounting behaviour have to be defined precisely, and then defined again after internal review or regulator feedback. This continues until launch day. 

2. Connecting to Everything Else: national payment rails, a correspondent or sponsor bank, card schemes and processors, identity and KYC/AML providers, credit bureaus, digital channels, and document providers. Each is a separate technical and commercial track. 

3. Designing Approvals and Authority: who authorises what, at which amount, with which document attached. It looks administrative, but it touches every process in the institution. 

Installing the core is not the bottleneck. What surrounds it is. 

Why Configurability Matters More Than Installation Speed 

Between licence and launch, plans change for reasons outside your control. A regulator asks for a product to be restructured. A partner’s timeline slips. A competitor launches, and the roadmap is rewritten in a single board meeting. So the question is not “how quickly can you install it”, but when the plan changes in month seven, how long does that change take? 

On the Fimple platform, a banking product is a definition, not a development project. Pricing, profit-sharing rules, charges, and accounting behaviour are configuration: versioned, testable before production, and owned by the business team rather than queued behind a release. We covered this in Advantages of Developing Products Without Source Code. 

This comes from architecture rather than effort. Because the platform is multi-tenant by design, a new institution is a tenant rather than an installation, and a new channel is a connection rather than a project. A participation bank on our platform went from start to live operations in approximately six weeks, with the licensing process, not the technology, setting the pace. It is also why more than 300 developers today build modules, screens, APIs, and integrations on Fimple without needing access to its source code. 

Why Integration Is the Hardest Part 

We have written before about why integration falters when you mix modules from different software companies. Everything in that article still holds, and for a newly licensed institution the consequences are sharper, because integration sits directly on the critical path to launch. In vendor selection it looks like a line item. In delivery, it looks like this: 

1. Every Connection Is a Contract: a commercial agreement, a technical specification, and an onboarding process on the counterparty’s side, none of it on your timeline. 

2. Data Models Rarely Agree: two systems describing the same customer or transaction describe them differently, and someone has to reconcile that difference permanently. 

3. Testing Is Harder Than It Looks: a sandbox may not exist, or may not behave like production. Retries, cut-off times, and settlement windows must be designed for failures you cannot reproduce in advance. 

4. Accountability Becomes Unclear: when something breaks between two vendors’ systems, determining responsibility takes longer than fixing the problem. 

5. Maintenance Never Ends: every upgrade your counterparty ships becomes your regression test. The cost is not building the integration; it is keeping it working for a decade. 

The cost also does not grow in a straight line: each additional system adds new failure modes between systems. Local payment rails deserve particular care. Since a national scheme arrives with its own message formats, mandatory fields, purpose codes, and cut-off times. 

Two Ways to Make Integration Easier 

Reduce the number of things you need to connect. This is what all-in-one should mean in practice: deposits and current accounts, lending, payments and local rails, cards, treasury, accounting and the general ledger, charges, collateral and limits, channels, document management, and a consolidated customer view in one platform, sharing one data model. Every module you do not buy separately is an integration you never have to build, reconcile, and maintain. Islamic banking capability shows what this means in practice. If you intend to offer Wakala-based and interest-based products side by side, that has to be a property of the product engine and the ledger. Selected when the product is defined and locked from that point onwards. It is not a switch someone turns on later. 

Make the integrations you do need uniform. But Fimple does not stop there, because all-in-one must never mean closed. Every function the platform performs also exists as an API. More than 10,000 of them today, so your mobile application, your branch screen, a fintech partner, and a national payment rail all come through the same door with the same contract. Beyond the interface, the process itself is designed rather than coded. As we described in Optimizing Financial Workflows with Fimple’s Process Designer. When a partner changes a step, that is a design change, not a development cycle, a release, and a regression window. 

Conclusion 

The months between a license and a first customer go to product definition, integration, and approval design, not to installing a core banking system. Institutions that meet their launch dates usually chose their platform on two criteria that never appear in a demo: how quickly it can be reconfigured when the plan changes, and how much of the first year’s requirement is already in the box. 

If your institution is inside that window, we recommend asking every candidate platform four questions: 

• How long until we have a working environment with our products defined in it, rather than a demo tenant? 

• What share of our product plan is configuration rather than development, and who performs it, your team or ours? 

• Of the capabilities we need in the first year, how many are in the platform today, and for the remainder, what exactly are we integrating? 

• When our plan changes in month seven, what does that change cost us in weeks? 

The fourth question is often the most revealing, simply because it is the hardest one to answer with a roadmap slide. 

A word on how to explore all four. Banking is a broad subject, and it is difficult to assess in one or two demonstrations. A short demo, ours included, will naturally follow a path that works well. What tends to help most is depth: sessions run against your own products, your own scenarios and the edge cases you already know are difficult. Together with conversations at institutions comparable to yours, in a similar market and with a similar product mix and scale. In our experience, a vendor who is comfortable being looked at that closely is usually a good sign. 

If it would be useful, we would be glad to go through these questions with your team, including the parts where the honest answer is “you will need to integrate that”. Let’s talk.