BNF Bank's Gone Wrong System Update

Introduction

In March 2025, Maltese BNF Bank plc (€1.28 billion in assets, 40,000 customers) initiated a critical IT modernization project involving its core banking systems, digital channels, a transition from VISA to Mastercard, and an account number change that also modified customers’ IBANs. However, the execution of this digital transformation took a decidedly calamitous turn. What was intended to be a seamless transition devolved into a textbook example of how a major IT upgrade can go spectacularly wrong. It checked all possible boxes in the worst ways: C-Suite handling of a disastrous outcome, Customer Relations, GDPR compliance, Security, Operations and, ultimately, failure to provide an improved solution for customers.

The Plan

It began with multiple notifications to customers that the Bank’s ATM network would be unavailable between 29th March 2025 and 1st April 2025. The downtime was planned to minimize customer impact since 30/03 was a Saturday and 31/03 was a Maltese public holiday. On April 1st, everything was supposed to return to normal with enhanced functionality.

The Outcome

1st April

When April dawned, it was apparent that things had not proceeded according to expectations. Customers who attempted to access their accounts via the web, the Bank’s mobile app, or ATMs were greeted with a completely collapsed IT system. The credit card system malfunctioned with customers reporting failed credit card purchases. Customer Care systems became overwhelmed and chaotic, with customers being directed to visit branches if they needed to conduct transactions.

2nd April

The Bank issued a statement claiming that “most of our customers successfully managed to go through this process, though there have been technical challenges.” This contradicted reality, with local and social media publicly reporting the exact opposite. BNF did not provide any indication of when systems would return to normal. When contacted by a local newspaper, a BNF spokesperson stated that “As can occur following a large-scale technological upgrade of this magnitude, we have encountered some technical challenges affecting certain functionalities.”

3rd April

Reports emerged that consumer rights advocates were calling for compensation for affected customers, particularly those who had faced late payment penalties or financial difficulties due to the extended outage.

4th April

BNF issued a notification informing users that the old IBANs would continue to work.

5th April

BNF issued a notification that Revolut accounts could no longer be topped up using their credit card. Only the Mastercard Debit Card would work. Revolut is very popular because it offers free services that BNF Bank normally charges for.

9th April …

According to local reports, the Maltese financial regulator, the MFSA, stated that it was “assessing and actively engaging with BNF Bank” after more than a week of customer complaints following its IT upgrade. The Bank advised customers requiring urgent transactions to visit branches where transactions would be processed free of charge. Angry customers also pointed out that the GDPR’s Data Protection Officer should investigate the matter.

15th April

BNF disabled comments on their social media platforms.

25th April

Local news outlets continued reporting that customers were facing problems almost a month after the update. Requests for a timeline on when issues would be resolved remained unanswered. When asked to comment on the disappearance of transactions, BNF stated: “We wish to clarify that issues relating to fund visibility are due to technical delays affecting transaction postings, and not from any loss of customer funds. Our technical teams are actively resolving these timing discrepancies to ensure clarity, consistency, and accuracy.”

5th May

BNF published a Press Release on their website from Mr. David Power, CEO of BNF Bank. Problems were still being reported.

What happened?

We can only accurately determine what happened if BNF Bank, the Financial Regulator, or another source with access to internal documents makes available an in-depth analysis. This should include what was originally planned, what controls and checks were in place to validate the original planning, and a detailed timeline of events starting on March 29th. The timeline should include:

When each outcome deviated from the plan
Discussions about these deviations and how action plans were adjusted
Whether there were any discussions about abandoning the upgrade and reverting to the existing system, and the justifications for not pursuing this route
Bugs that were not detected in pre-migration testing and how these were managed
Actions the Bank implemented to mitigate failures in the upgrade process

Observational Comments

BNF Attempted Too Many Simultaneous Changes

The “Big Bang” upgrade was too extensive to manage effectively from both an operational perspective and in terms of customer communication. Even if the upgrade had worked flawlessly—which it clearly did not—communicating so many changes to customers simultaneously would have overwhelmed them and disrupted their ability to transact. For example, certain customers were receiving credit card upgrades related to their existing VISA cards at the same time they were receiving documentation regarding their new Mastercard. The timing overlap between when cards were posted and when PINs were sent compounded the confusion.

The same reasoning applies to the IBAN number changes. During the upgrade crisis, BNF Bank informed customers that both IBANs would remain operational, indicating this approach was doable. This raises the question of why they didn’t postpone the IBAN transition—which impacts numerous automated payment flows—to a later date.

While it’s uncertain whether splitting the process into multiple stages would have impacted the timeline, it would certainly have reduced much of the resulting confusion and prevented completely locking customers out of all access channels to their funds. It would also have mitigated the risk of the embarrassing failure that ensued.

BNF Lacked Sufficient Resources for Such a Major Upgrade

When a system overhaul encompasses everything except the company’s name and logo, customer difficulties should have been anticipated and planned for, despite extensive advance notifications. The bank did not adjust opening hours to support clients (the two outlets that operated evening services had been doing so since January). Given that every client-facing system was being replaced, the bank should have implemented 24-hour human-operated call centers and walk-in sites with properly trained personnel equipped with appropriate tools to resolve customer problems.

Whether the bank had the required number of trained personnel necessary for such an upgrade remains unknown.

Inadequate Communication and Pattern of Denial

BNF never explicitly acknowledged that their upgrade was a failure. Initially, their messaging was worded to suggest that only a small subset of clients was impacted, which was not the case. Failing to admit that the upgrade had gone critically wrong likely contributed to their inertia in reinforcing support services. This communication failure further frustrated customers who lost access to their money and their ability to transact and meet financial obligations.

Insufficient Preparation

Evidence of poor preparation for the upgrade includes: - GDPR breaches in some accounts. For example, in joint accounts, if A and B had a joint account, and B and C had another joint account, A could see the joint account of B and C. - Inconsistent account display formatting with some accounts showing in all caps while others appeared in mixed case. - Planned downtime that extended by almost two weeks, with nearly a month passing before operations returned to relative normality. - Transactions appearing as “Domestic Clearing” without descriptions of the true source/destination of funds, even though records were being updated post-upgrade. The dates of such transactions indicate that systems were still not operating correctly a month after the upgrade.

An upgrade of this scale requires:

Comprehensive System Assessment that audits existing systems, factors in customizations, and maps data silos.
Stakeholder Alignment & Governance with a Project Management Office (PMO) to coordinate different systems and departments, align efforts, and manage and adjust timelines and budgets.
Data Preparation & Migration Strategy:
- Conduct data triage:
  - Clean corrupt/inconsistent records
  - Make decisions regarding obsolete historical data
  - Create field-level mappings between legacy and new systems
- Implement pilot migrations with representative data subsets to validate transformation rules and estimate upgrade times, including system unavailability periods
- Engage a small sample of customers representative of the account base to participate in the pilot
Risk Mitigation Planning:
- Parallel run testing, in which both legacy and new systems operate concurrently for 6-8 weeks to validate functionality and output consistency
- Failback protocols that establish clear thresholds for aborting the upgrade with automated monitoring to detect anomalies in real-time

Although neither the legacy nor the new systems are known, BNF Bank is a small institution with a few million accounts at most. Furthermore, BNF Bank is a relatively new bank, having been incorporated in 2007. This raises questions about why the bank was unable to perform a simulated full upgrade prior to the actual implementation. Such an approach would have made it possible to parallel-run the majority of the core systems.

UX/UI

BNF Bank did not update their existing mobile app but instead published a completely new one. This meant that customers did not receive the new app as part of their app store’s periodic updates but were expected to search for and install it manually. The new app’s name did not begin with “BNF” nor resembled the original in appearance.

Both the mobile app and the web portal presented users with three options to choose from. Rather than requesting the username first and then routing customers to the appropriate screen, customers were expected to click on the links at the bottom. If a link did not apply to them, they still received SMS notifications rather than being informed that they had already completed that stage / it did not apply to them.

The On/Off toggle switches on the Mobile app are the reverse of what is UI design convention. Normally On/Enabled has the toggle on the right.

Security

The Good, the Bad, and the Useless

Put succinctly, the primary purpose of security is to protect assets by securing every ingress point without encouraging third parties to weaken entry points through overly complicated requirements. For example, if an organization were to force passwords to be 20 characters long, prohibit two numbers or two letters from appearing adjacent to one another, and require changes every month, the likely outcome would be users writing passwords on paper rather than memorizing them. Furthermore, the frequent update requirement would cause many customers to simply cycle the last digit. (See: https://neal.fun/password-game/). While from the entity’s perspective their password system might appear secure, from a holistic perspective it would not be. Adding unnecessary and unjustified friction to the customer experience without security gains only worsens that experience and encourages behaviours that ultimately weaken overall security.

SMS verification is used for both the mobile app and the web portal. Most web portals that use SMS verification rely on 6-digit codes. Longer numeric strings or alphanumeric codes only add friction for customers who must copy additional characters to perform tasks, increasing the risk of errors that invalidate transactions or trigger account lockouts.

Best practices include sending notifications to customers when login attempts occur on their accounts, especially from unfamiliar locations or devices. After multiple failed attempts, accounts should be temporarily locked with clear information provided about the lockout duration and identity verification procedures to expedite resolution.

Some institutions allow customers to validate specific browsers, eliminating the need for repeated verification steps. Companies that provide both web and app interfaces typically use the same credentials, avoiding the need for customers to remember different credentials. On mobile devices, password entry can be bypassed through biometric authentication.

Security at BNF Bank

Some SMS messages sent by BNF contain alphanumeric codes. Unlike numeric codes, these cannot be copied by simply tapping on the SMS link. The workaround requires selecting the entire message, copying it to an editor, selecting the relevant portion of the code, copying it again, and then pasting it into the app—a process that is trivial for hackers but challenging for many general users. What justification exists for using an 8-character mixed-case alphanumeric string that cannot be copied instead of a 6-digit number?

The credentials for the mobile app and web portal are different. While the mobile app supports biometric authentication, customers who cannot use their fingerprint or face will likely end up locking themselves out.

BNF does not offer clients the ability to validate their home browsers, thereby eliminating the need for additional authentication actions.

If customers lock themselves out, all access is blocked. For example, if a lockout occurs on the internet portal, mobile access is also suspended. There is no timeout after which the lock is automatically released, and the only way to regain access is to physically visit a bank branch.

Conclusion

If this were a comedy, people would come out of the theatre in a happy and joyous mood. BNF Bank’s disastrous upgrade, how they interfaced with customers and impractical measures they have should be reviewed and overhauled to be functional and practical while remaining secure. Whether the general public every finds out what went wrong depends primarily on legal challenges, and actions by the FSA and the GDPR offices.