A bank built in 8 months - licence confirmed, deadline met

Build or buy? When the client came to us, that question was still open. We recommended building. No vendor lock-in, no paying for features you'll never use, no waiting on someone else's roadmap. A codebase you own. A product you control. They agreed. That put more weight on us - and we were fine with that.

When a financial institution receives a banking licence, the clock starts ticking immediately. Regulators don’t hand out licences and walk away — they expect proof that the bank can actually operate. In our client Iute’s case, that meant completing at least one real SEPA payment within 8 months of getting us on board.

Eight months to build a bank. We thought — we know banking, we are ready.

About Iute

Iute Group is a digital banking group focused on everyday financial services in Southeast Europe. Established in 2008 and headquartered in Estonia, Iute serves customers in Albania, Bulgaria, Moldova, North Macedonia, and Ukraine. Through the Myiute app and its local operations, Iute provides digital financial services including payments, banking, financing, and insurance intermediation. Iute Group finances its operations through equity, deposits, and secured bonds listed on the Regulated Market of the Frankfurt Stock Exchange and the Nasdaq Baltic Main List.

Two teams building one bank in parallel

What made this project unusual wasn’t just the deadline. It was the way Iute approached it. While we were assembling the technical foundation, the client was simultaneously building their business team — hiring compliance officers, payment specialists, product owners — week by week.

This could have been chaos. Instead, it became one of the most naturally agile projects we have worked on.

Both sides moved in weekly cycles. Every week, the client’s business team clarified a new slice of requirements — often for processes they themselves were still figuring out. Every week, we delivered working software. There was no big specification document handed over at the start. There couldn’t be — it didn’t exist yet. The bank was being designed and built at the same time, by two teams running in parallel.

We met once a week. We discussed what the business needed next. We built it. We showed it. We moved on.

SEPA: not just a checkbox

To confirm the licence, the bank needed to execute at least one genuine SEPA credit transfer before the regulatory deadline. Not a test transaction. A real one, going through the actual payment infrastructure.

This sounds deceptively simple. It is not.

SEPA integration means connecting to a payment scheme — in practice, going through a clearing and settlement mechanism that has strict technical and operational requirements. Messages must follow ISO 20022 format exactly. Processing windows, cut-off times, and settlement cycles are not flexible. Reject handling, return flows, and reconciliation all need to work correctly from day one — because in payments, “almost correct” is the same as broken.

On top of the technical layer, there is the compliance layer. Every outgoing payment must pass through sanctions screening, AML checks, and the bank’s own internal controls before it can leave. These systems had to be in place and working before a single real payment could go out.

Getting SEPA live means building the full stack: connectivity to the scheme, message processing engine, payment lifecycle management, compliance integrations, back-office tools for operations staff — and enough automated testing to be confident that none of it silently breaks under edge cases.

We hit the deadline. The transfer went through.

PSD2: the other half of the foundation

Alongside SEPA, we built PSD2 compliance into the bank from the ground up. PSD2 — the EU’s Payment Services Directive — requires banks to expose standardised APIs so that licensed third-party providers can access account information and initiate payments on behalf of customers.

For a newly licensed bank, this is not optional and not small. The directive mandates specific API interfaces, strict authentication flows (Strong Customer Authentication), and a sandbox environment for third parties to test against — all before the bank goes live.

Building PSD2-compliant APIs meant implementing the full open banking stack: account information services, payment initiation services, consent management, SCA challenge flows, and the dedicated interface the regulator requires. Each of these touches the core banking system, the authentication layer, and the customer-facing products simultaneously.

Two large, interconnected workstreams. Both had to be done correctly, not approximately. Both were delivered within the same 8-month window.

What actually made it work

Looking back, the speed came from the way both sides worked — not from cutting corners.

Iute had a strong product owner who made decisions quickly. When we showed working software, they gave real feedback, not committee feedback. When requirements changed mid-week — and they did — we adapted without making it a crisis.

On our side, we kept the scope ruthlessly focused. We asked constantly: what is the minimum needed to do this correctly? Not to do it cheaply — but to do it without waste. Every feature had to earn its place.

No project managers. No handoff documents. Developers talking directly to the business. Weekly rhythm, working software, honest conversations about what was possible.

A bank is live

Eight months after we started, the bank had a confirmed licence, a working core, SEPA payments processing, PSD2 APIs in place, and a team that knew how to operate it.

Regulatory deadlines are usually the enemy of good software. This time, they forced exactly the focus and discipline that made the project succeed.

Thinking about building a bank or financial platform under time pressure? Let’s talk.