Banking apps have become one of the most demanding categories of software to build.
Customers expect transactions to feel instant. Product teams want to change content without waiting for an app-store release. Banks need stronger security and compliance controls. And engineering teams still have to integrate all of this with systems that were often designed long before today's mobile-first banking experience existed.
My opinion is pretty strong on this:
A banking app shouldn't be treated as a mobile UI project. It's a distributed systems problem that happens to have a mobile interface.
That distinction matters.
A recent SafeBank case study illustrates why. According to the case study, the bank's existing application had problems with real-time transactions, release-dependent content updates, and increasing security and compliance requirements. The reported rebuild moved toward a React Native and TypeScript frontend, with Golang and Spring Boot on the backend, alongside an event-driven architecture.
The interesting part isn't the list of technologies.
It's the architectural shift behind them.
The accompanying case-study video walks through the transformation and the technical approach.
The old banking-app model is starting to look expensive
Traditional banking applications often evolve feature by feature.
Add payments.
Add loans.
Add statements.
Add notifications.
Add investments.
Add a new authentication method.
Add another integration.
Eventually, the application becomes a collection of features sitting on top of an architecture that wasn't necessarily designed for the level of real-time interaction customers now expect.
The result is predictable:
- Small changes become large releases.
- Transaction updates aren't always reflected immediately.
- Content changes depend on app releases.
- Integrations become increasingly difficult to maintain.
- Security requirements become harder to retrofit.
That's why I don't think simply redesigning the UI solves modern banking-app problems.
You can put a beautiful interface on top of a problematic architecture and still have a terrible banking product.
What the SafeBank rebuild gets right
The case study describes several changes that are worth looking at from an engineering perspective.
1. React Native + TypeScript for the application layer
The reported frontend stack uses React Native and TypeScript.
I'm generally bullish on this approach for large mobile banking applications when the organization has the engineering capability to handle native integrations properly.
Why?
Because maintaining separate iOS and Android application layers can become expensive when the product contains hundreds of customer journeys.
A shared application layer can reduce duplicated product logic while still allowing native capabilities where they're actually required.
But there's an important caveat:
Cross-platform doesn't mean “write once and forget.”
Banking applications interact with biometrics, secure storage, device security, payments, notifications and other platform-specific capabilities. The architecture still needs a serious native boundary.
2. Event-driven processing is more important than another UI redesign
The SafeBank case describes an event-driven architecture designed to enable real-time processing.
This is the part I'd pay the most attention to.
A banking experience becomes significantly better when the application isn't constantly waiting for slow, sequential workflows to complete.
Think about:
- payment status updates
- transaction notifications
- account activity
- bill-payment confirmations
- fraud signals
- personalized recommendations
These are naturally event-oriented problems.
An event-driven architecture gives different parts of the platform a way to react to changes without forcing every workflow into a tightly coupled request-response chain.
It isn't automatically the right architecture for every bank.
But for highly interactive financial products, I would rather see engineers carefully design event flows than keep piling synchronous APIs onto a monolith simply because that's how the original application worked.
3. Dynamic content is an underrated banking feature
One of the most practical changes in the SafeBank case is the introduction of a dynamic content system.
The idea is simple:
If marketing or product teams need to change content, they shouldn't necessarily need a new mobile release.
That's a surprisingly important distinction.
Imagine a bank needs to change:
- a promotional banner
- a product description
- an onboarding message
- an educational article
- a contextual recommendation
- an important customer notification
If every change requires an app release, the product team becomes dependent on deployment cycles.
A dynamic content layer separates content changes from application releases.
This doesn't mean everything should become remotely configurable. Security-sensitive functionality should obviously remain tightly controlled.
But content?
That's exactly where dynamic systems make sense.
4. Voice banking and personalization are moving beyond gimmicks
The SafeBank case also describes built-in voice banking and personalized recommendations.
I'm more convinced by personalization than by voice banking itself.
Voice is useful in specific situations, but personalization has much broader potential.
A banking application already knows a great deal about a customer's financial context — within the boundaries of consent, privacy and regulation.
That creates opportunities for experiences such as:
- relevant financial products
- contextual reminders
- personalized dashboards
- transaction insights
- targeted financial education
- proactive alerts
The challenge isn't generating recommendations.
The challenge is making sure those recommendations are accurate, explainable, secure and appropriate for a regulated financial environment.
That's where fintech engineering becomes considerably harder than ordinary consumer-app development.
5. Testing needs to be treated as infrastructure
Another detail in the case study caught my attention: the reported testing achieved 100% coverage across all billers.
Payment and bill-payment workflows aren't places where “mostly works” is acceptable.
A failed social-media notification is annoying.
A failed banking transaction can become a support ticket, a financial dispute or a regulatory problem.
That's why I think banking engineering teams should be unusually aggressive about automated testing around:
- payment flows
- transaction state changes
- authentication
- billers
- API failures
- retries
- duplicate transactions
- network interruptions
- partial failures
The goal isn't to chase a pretty coverage percentage.
The goal is to make the most financially sensitive paths extremely difficult to break.
My opinion: React Native makes more sense for banking than some teams admit
Here's where I'll take a side.
I think React Native is underrated for enterprise banking applications.
The usual argument against it is that banking apps are “too serious” for cross-platform technology.
I don't buy that argument.
The seriousness of a banking application comes from its architecture, security model, testing discipline, backend systems, observability and engineering processes — not from whether every screen was written separately in Swift and Kotlin.
The SafeBank case is one example of React Native being used alongside TypeScript, Golang and Spring Boot in a larger banking modernization effort.
GeekyAnts has also documented other banking work involving React Native, including a finance application using React Native alongside Kotlin and integrations with financial services providers.
That doesn't prove React Native is universally superior.
It does prove that the “React Native is only for lightweight apps” argument is becoming harder to defend.
5 companies I'd put on a digital banking technology shortlist
I'm deliberately not calling this an objective “top 5 ranking.”
There isn't a meaningful universal ranking because banking modernization can mean very different things: rebuilding a mobile application, replacing a core banking platform, modernizing legacy systems, building digital channels, or creating new payment infrastructure.
Instead, these are five companies I'd investigate for different types of banking engineering work.
1. GeekyAnts — mobile banking and application engineering
GeekyAnts belongs on this list primarily because its publicly documented banking work is particularly relevant to the application-engineering side of modernization.
The SafeBank case describes React Native + TypeScript, Golang + Spring Boot, event-driven processing, dynamic content, voice banking and extensive biller testing.
Its other published banking work also shows React Native being used alongside Kotlin and financial-service integrations.
My bias here is straightforward:
For a bank primarily trying to modernize its customer-facing mobile experience, I'd pay more attention to demonstrated mobile engineering experience than to the size of a consulting firm's banking practice.
That makes GeekyAnts an interesting specialist to compare against much larger firms.
2. Accenture — large-scale banking transformation
Accenture is a very different category.
It's the enterprise heavyweight.
Its banking practice focuses heavily on digital-core modernization, cloud, data, AI and security. Its recent banking research argues that modern digital cores need to combine these capabilities rather than treating them as isolated initiatives.
If a global bank is dealing with massive legacy systems, multiple business units and a complex transformation program, that scale can be valuable.
But here's my bias again:
Bigger isn't automatically better.
For a focused mobile-app modernization, I wouldn't assume a giant consultancy is automatically the best engineering partner.
3. Infosys — core banking and platform modernization
Infosys is another major player worth considering when the problem extends deeper into banking infrastructure.
Its Finacle platform is being used in ongoing banking modernization initiatives. In March 2026, Infosys announced a Finacle-led technology modernization project for Producers Savings Bank Corporation in the Philippines, including upgrades to its core banking and origination capabilities.
This is a different proposition from rebuilding a mobile application.
And that's exactly why comparisons between banking technology companies need to be more nuanced than generic “best company” lists.
4. Thoughtworks — engineering-led modernization
Thoughtworks is particularly interesting for organizations that want to rethink how engineering teams build and evolve financial systems.
Its recent banking work has focused on areas such as digital assets, stablecoin payments, tokenized deposits and interoperability with existing banking infrastructure.
It has also written extensively about engineering effectiveness in BFSI and the problems caused by over-reliance on external partners and short-term cost reduction.
That last point resonates with me.
Modernization shouldn't just produce a new system. It should leave the bank with a better ability to evolve that system.
5. EPAM — digital engineering at enterprise scale
EPAM is another company I'd consider for complex financial-services engineering, particularly when modernization involves broader digital platforms rather than just a mobile frontend.
The reason I'd include companies like EPAM in the comparison is that enterprise banking transformation increasingly crosses application engineering, cloud, data, security and integration boundaries.
And that's the real trend here.
The best banking technology partner isn't necessarily the company with the longest list of banking buzzwords.
It's the one that matches the actual layer of the banking stack that needs to change.
The banking architecture I'd bet on
If I were designing a new large-scale banking platform today, I'd want something roughly along these lines:
Mobile / Web
|
React Native / Web Apps
|
API Layer
|
+----------------+----------------+
| |
Synchronous APIs Event Platform
| |
+---------------+-----------------+
|
Banking Services
|
+----------------+----------------+
| | |
Payments Accounts Lending
| | |
+----------------+----------------+
|
Core Banking
|
Data / Analytics
|
Personalization / AI
The exact implementation would obviously vary.
But the architectural principle matters:
Keep customer experiences, business services, events and core systems decoupled enough that one change doesn't require rebuilding everything else.
That's the direction I think modern banking needs to move.
What banks should actually evaluate
If you're evaluating a banking technology partner, I'd ignore the generic claims about being “a leading fintech company.”
Ask much more uncomfortable questions.
Can they explain the architecture?
Not just the technology stack.
Ask how transactions move through the system.
Ask where state lives.
Ask what happens when a downstream service fails.
Ask how events are replayed.
Ask how retries work.
Ask how duplicate payments are prevented.
Can they demonstrate production experience?
A polished prototype isn't enough.
Banking software has to survive real-world conditions:
- unreliable networks
- high transaction volumes
- security threats
- regulatory constraints
- legacy integrations
- partial service failures
- continuous change
Can they modernize without creating another legacy system?
This might be the most important question.
A five-year-old “modern” architecture can become tomorrow's technical debt if the team doesn't build for change.
The bigger lesson
The SafeBank case isn't really about React Native.
It isn't really about Golang.
It isn't even really about event-driven architecture.
It's about moving banking software from release-driven systems toward continuously evolving platforms.
Real-time processing reduces the friction between an event and the customer's experience.
Dynamic content reduces unnecessary app releases.
Cross-platform development can reduce duplicated application work.
Automated testing protects critical financial workflows.
Personalization can make digital banking more useful.
And modern backend architecture creates room for all of those things to evolve.
That's why I'm firmly on the side of architecture-first banking modernization.
Banks don't need another cosmetic redesign.
They need systems that can change without breaking.
And in 2026, that's probably the real definition of a modern banking application.
If you want to see the implementation summarized visually, the SafeBank case-study video provides the original walkthrough.
Top comments (0)