Garanti BBVA Mobile App Crash, What Happened and Why

Last week, the digital channels of Garanti BBVA, one of Turkey’s leading banks, became unusable for about 12 hours. Users ran into critical errors while logging in, and logging in to the Garanti BBVA mobile app was not possible. So what was behind this outage? Since the bank did not give a technical explanation about the errors, it is not possible to give a definite opinion here. Let’s look at both the errors and the possible results with a neutral and skeptical eye.

Garanti BBVA Mobile App Problems, What Do the Technical Errors Say?

When users tried to log in to the app, they got the error in the screenshot above. The part that stands out here is the code below:

pgsqlKopyalaDüzenlejava.lang.IllegalStateException: The method is called on an invalidated session: overflowed-session

This error directly points to a serious problem in session management.

The scenario that appears from here is that the Garanti BBVA mobile app tried to process user sessions that had become invalid. This seems to have led to a session overflow problem across the system. The errors appear to have locked the application layer in a chain reaction, preventing users from accessing the app.

This kind of error, especially in Java based applications and especially on powerful server infrastructures like IBM WebSphere Liberty, leads to an IllegalStateException error. It can come from several reasons, such as improper session handling, Garbage Collection (GC) processes not being triggered correctly in backend systems that manage sessions, or the session invalidation mechanism not working properly.

When Garbage Collection processes do not work properly, unused session data can build up in memory and cause session overflow. This leads to the session becoming invalid and, as a result, the IllegalStateException being thrown. Also, when a session expires, if the session invalidation mechanism does not work correctly, this can also cause errors like this.

In short, this failure in session management can lead to much heavier results in high traffic systems like banking apps where millions of users process transactions at the same time. This kind of error seriously affects the user experience and can also bring security risks. Session management should always be monitored and tested carefully, especially in critical apps.

Garanti BBVA’s Use of IBM Technologies, Tivoli and Federated Identity Manager

We assume that Garanti BBVA uses IBM Tivoli Federated Identity Manager (FIM) infrastructure in identity management and session verification processes.

This system:

• Provides centralized session control across all digital channels.
• Manages the customer experience through a single sign on (SSO) mechanism.
• Keeps credentials and user permissions in a federated structure.

However, when this kind of central system malfunctions, it can stop all digital transactions. It increases the risk of a “single point of failure” (SPOF). So it is highly likely that Garanti BBVA’s infrastructure is directly related to the outage that happened.

Is the IBM Security Bulletin Related to the Garanti BBVA Outage?

After this event, IBM published a security bulletin about vulnerabilities found in WebSphere products. Bulletin link This bulletin mentions vulnerabilities against uncontrolled growth in memory consumption (memory leak) and denial of service attacks (DoS).

At this point, it is not possible to say there is a direct link between the outage Garanti BBVA experienced and IBM security vulnerabilities. But since the bulletin date is after the event and products like Tivoli are thought to use services in this bulletin, indirect effects should not be ignored.

Especially factors like missing patch management and outdated system components can open the door to chain failures.

Will Debts at the Bank Be Erased?

When such major system outages happen, one of the questions often asked in public is, “Will our debts be erased?” But the answer is very clear, No, that is not possible.

Banks do not store their data on just one server. On the contrary, they have backup systems running constantly between Active Active and Active Passive data centers. They also create offsite repository backups in completely different geographic regions for use in a possible disaster. On top of that, these data centers keep customer information and account movements up to date by copying them in real time.

For this reason, when a system error or access outage happens, it is not technically possible at all for debts to be erased, credit records to disappear, or account balances to be reset to zero. Multi layer security and backup protocols are used in the banking sector to protect this kind of data.

As a result, we should not pay attention to rumors spreading on social media like “debts were erased.” Reality lies in the solid structure of banking infrastructure.

Final Word;

This event showed us that in critical sectors like banking, even a seemingly small error can make entire digital systems unusable for hours. Central identity management systems especially make the user experience easier, but they also bring serious security and access risks.

Also, when technical details are not shared in official statements, we learned once again how important it is to approach the seriousness and scope of events with skepticism. Transparency and proper information become vital for both institutions and users during a crisis.

Another important lesson is the fact that being ready for disaster scenarios in the banking sector is no longer a choice, it is an absolute necessity. Having complete backup, system continuity, and quick response plans makes a difference in moments like this.

Now attention is on what lessons both Garanti BBVA and other players in the sector will take from this serious outage. Of course, BDDK also has a very big role here. Like the bank, BDDK also needs to share the event with the public in a transparent way.

Since the bank did not make a technical explanation, everything in this post is only scenarios for expressing an opinion.