Mobile banking app development: fast, safe and auditable
APIs, authentication, core-banking integration, notifications and the performance work behind a mobile banking app, in Java and Spring. The mobile client is built by your team or a partner we work alongside; the platform underneath is ours to get right.
- 300,000,000
- queries a day on a search back end we redesignedUK hotel metasearch engine
- -60%
- response time on the same system after the redesignUK hotel metasearch engine
- 1,000,000,000
- transactions an hour on an in-memory ledgerFastPost, developed for Legerity from 2013
- Who it is for
- Banks and fintechs launching or replacing a mobile channel, and mobile teams who need a back end that will not be the slow part
- What we build
- The API layer, strong customer authentication and session security, core and card-system integration, push and event notifications, caching for sub-second screens, monitoring
- What we do not build
- The iOS and Android clients. We design the API for the team that does and work in their weekly cadence
- How it is sold
- A written ballpark after the scoping call, then Modernization Sprints on an existing back end or a time and materials build for a new one; Team Extension when you own the roadmap
What banks want from a mobile channel
Screens that answer in under a second
Even when the core behind them cannot, because the platform caches and aggregates for it.
Old app versions that keep working
Versioned APIs, so customers who have not updated are not cut off.
Strong authentication without friction
Step-up only for the actions that need it, to the PSD2 rules and ready for PSD3.
An app team that ships every week
A back end that never becomes the reason a release slips.
The platform behind the app
API layer designed for a mobile client
Screen-shaped endpoints, versioned so old app versions keep working, with the latency budget agreed up front and measured in production.
Authentication and session security
Strong customer authentication, device binding, token lifecycles and step-up for sensitive actions, built to the PSD2 rules and ready for PSD3.
Core and card integration
Balances, transactions, payments and card controls read from and written to the core through an integration layer that survives the core's batch windows.
Caching for sub-second screens
In-memory data grids where the core cannot answer in the time a screen has, with staleness rules defined per data type rather than discovered by customers.
Notifications and events
Kafka-backed event streams driving push notifications, fraud alerts and the activity feed, with ordering and replay handled.
Observability and support
Per-endpoint latency and error budgets, and a Managed Java Application Support retainer if you want the platform run for you.
Back ends that carry the load
- Flagship · Travel · 2019
UK hotel metasearch: 300 million queries a day at 80 percent lower cost
A SQL Server cluster that stopped scaling replaced by an in-memory data grid: 50 percent more traffic, 60 percent lower response time, 80 percent lower infrastructure cost.
300,000,000 queries / day
- Flagship · Banking and fintech · from 2013
FastPost: a billion financial transactions in under an hour
FastPost, a rule-driven, high-performance accounting platform developed for Legerity by Stratoflow from 2013, used by telcos and insurers worldwide.
1,000,000,000 transactions / hour
Services for mobile banking platforms
Most banking apps are slow because of the back end, not the app
A mobile screen that waits on three synchronous calls to a core banking system will be slow no matter how well the client is built. The work that makes an app feel fast is caching, aggregation and asynchronous design behind the API, and that is Java engineering of the kind we have done at 300 million queries a day.
We do not build the mobile client. We have tried the alternative of taking whole projects and subcontracting the part we do not do, and it produced worse results for everyone. We will say so on the scoping call and suggest how to structure the two teams.
Mobile banking back ends, the practical questions
Why not build the whole app?
Because native mobile development is a different craft with its own release process, and we would be subcontracting it. Clients get a better result from a mobile team that owns the client and a back-end team that owns the platform, working in the same weekly rhythm. We have done it that way and it works.
Can you work with our existing core banking system?
That is usually the whole job. The integration layer is designed around what the core can expose and how fast, including its batch windows, and the caching strategy fills the gap between that and what a screen needs.
How do you handle strong customer authentication?
To the PSD2 regulatory technical standards, with device binding, token lifecycles and step-up for sensitive actions, designed so the tightening expected under PSD3 is configuration rather than a rebuild.
Who owns the back end you build?
You do. It is built in repositories you control, ownership is assigned to you in the agreement, and handover is part of the scope if your own team takes it over.
Is your team big enough to work alongside ours?
A boutique team of senior engineers, all direct employees. That is the right size for a back-end team working in the same weekly rhythm as your app team.
What technology runs behind the app?
Java and Spring for the API layer, an in-memory data grid for sub-second screens, Kafka for notifications and the activity feed, and the core's own interfaces behind an integration layer.
Around mobile banking
Book a scoping call
Thirty minutes with an architect, not a salesperson. You leave with a written view of scope, price model and whether we are the right team for it.