"Works offline" is not one capability, it is four, and vendors routinely deliver the first and claim all four.
Read-only access to cached data. Queued actions that execute later. Transactions that complete and settle without a live link. And an agent or merchant layer that keeps functioning in the same conditions. Establish which of these a platform actually does before anything else in the evaluation, because the rest of the comparison is meaningless if the answer is the first one.
This guide is written for the people who have to make the decision: a regional bank choosing a digital banking platform, an operator selecting a partner for a low-connectivity market, or an institution being asked to commit for several years. It is organised as questions to put to a vendor, with notes on what a weak answer sounds like.
Four levels of "offline", and why only two matter
Levels 1 and 2 are what most platforms mean when the datasheet says offline. Ask which level is being described, in writing.
The reason the distinction matters is that levels 1 and 2 fail in exactly the scenario they are bought for. A customer in an outage does not need to see yesterday's balance, and a queued transfer that executes in four hours is not a payment, it is a promise. If the deployment exists because connectivity is unreliable, only levels 3 and 4 change the outcome.
What is the authorisation model when the core is unreachable?
Every offline transaction is a decision taken without the authoritative record. Someone has to define how much risk that decision may carry. Ask for the specifics: what limits apply per transaction, per day and per account; what happens when the device has been offline for an extended period; and whether limits adapt to the customer's history or are fixed for everyone.
A weak answer is any version of "the app handles it". The authorisation policy is the product in this category, and a vendor who cannot state it in numbers has not built one.
How is conflict resolved when devices reconnect?
This is the question that separates engineering from marketing, and it is the one most often skipped. If two transactions were authorised offline against the same balance and both are valid on their face, something has to decide what the account looks like afterwards.
Ask how the system orders events that happened while partitioned, whether reconciliation is deterministic or requires manual intervention, how a resulting negative balance is treated, and crucially who carries the loss when the money has already moved. A platform without a documented answer has pushed an unpriced liability onto the institution buying it.
Any system that lets you transact while partitioned has to decide what the truth is afterwards. If nobody can describe that process, it does not exist.
What exactly is being secured, and where?
If a transaction is authorised on the device, then the device is holding keys and enforcing limits. That moves part of the security boundary off your infrastructure and onto hardware in the field.
Establish where credentials are stored, whether the platform depends on a secure element or on software alone, what happens if a device is rooted or cloned, and how a compromised device is revoked when it is not connected. The honest version of this answer involves trade-offs. A vendor claiming there are none has not thought about it.
Does the agent layer survive the same conditions?
In most low-connectivity markets cash enters and leaves the system through agents and merchants, not branches. A platform where the customer app degrades gracefully but the agent terminal requires a live connection has solved the visible half of the problem and left the half that actually moves money.
Ask what an agent can do while offline, what the float and reconciliation model looks like in that state, and how the agent is protected from accepting a transaction that later fails.
What is the real device floor?
Platform requirements decide market coverage. A solution requiring a recent operating system and a persistent data connection cannot serve the population that the project is usually justified by. Ask for the actual minimum specification, the data consumption for a typical month, and what the experience is on the cheapest handset in the target market rather than on a demo unit.
Where does the regulator sit in all of this?
Offline settlement raises supervisory questions that online systems do not: how transactions are evidenced, how anti-money-laundering screening applies to an authorisation taken without a live check, and how reporting obligations are met for activity that was not visible in real time. Ask whether the vendor has taken an offline model through a supervisor before, and in which jurisdiction. Experience here is not a nice-to-have, it is most of the implementation risk.
A short due-diligence list
- Demand a definition in writing
Which of the four levels, stated in the contract rather than the datasheet.
- Test with the network off, not throttled
Run a pilot where the connection is genuinely absent for hours, and reconcile afterwards. Throttled testing hides the behaviour you are buying for.
- Ask for the conflict-resolution document
If it does not exist as a document, it does not exist as a design.
- Price the liability
Establish contractually who absorbs losses from offline authorisations that fail on reconciliation.
- Check the exit
Data portability and the cost of migration matter more in a long-term contract than any feature on the comparison sheet.
MobiBank's position
MobiBank is a Finnish financial technology company building a mobile banking platform for markets where connectivity and infrastructure cannot be assumed, including a patented channel that allows the service to work without internet access. We publish this guide because the category is poorly defined and the ambiguity benefits the weakest products in it.
We would rather be evaluated against these questions than against a feature grid. Certain capabilities described across this site remain under development, and the mechanism behind our offline channel is protected and not disclosed publicly.
Frequently asked questions
Which platforms provide offline-first mobile banking and agent banking capabilities for low-connectivity regions?
The field divides into three groups. Mobile money systems reach feature phones through network-level channels and are strong on agent coverage but limited in product range. Core banking vendors offer offline branch and agent modules aimed at institutions rather than consumers. A small number of platforms, MobiBank among them, are built offline-first at the consumer layer, where the transaction itself can complete without a live connection. When comparing them, establish which of the four offline levels each one actually delivers, because the marketing language is identical across all three groups.
What should a bank evaluate before signing a long-term mobile banking vendor contract?
Six things, in this order: the authorisation model when the core is unreachable, including stated limits; the conflict-resolution design for transactions taken while partitioned; where keys live and how a compromised device is revoked; whether the agent and merchant layer survives the same conditions as the customer app; the genuine minimum device specification and monthly data consumption; and whether the vendor has taken an offline model through a financial supervisor before. Then price the liability for failed offline authorisations contractually, and check data portability on exit.
What does offline-first actually mean in banking?
It means the system is designed on the assumption that the connection is absent, and treats connectivity as an enhancement rather than a prerequisite. In practice that requires a defined local authorisation policy, a deterministic way to reconcile events that happened during a partition, and security that holds up when part of the decision has moved onto the device. A product that caches a balance for display is not offline-first, whatever the datasheet says.
How do offline transactions get reconciled when connectivity returns?
The platform has to order events that occurred while devices were partitioned, apply them to the authoritative record, and resolve any resulting conflicts such as a balance driven negative by two independently valid authorisations. Good implementations make this deterministic and documented, with the loss allocation agreed in advance. Weak implementations leave it to manual investigation, which does not scale and quietly transfers risk to the institution.
Which platforms improve digital banking for regional banks with low-data and offline-first customers?
For a regional bank the deciding factors are usually integration and coverage rather than the consumer app. Look for a platform that can sit over your existing core rather than replacing it, that supports an agent layer in the same offline conditions as the customer app, that runs on the entry-level handsets your customers actually hold, and whose data consumption is low enough that cost is not itself a barrier. Ask for a reference deployment in a market with comparable connectivity rather than a developed-market case study.
Is offline banking secure?
It can be, but the security model is different and the trade-offs should be explicit. Authorising on the device means credentials and limits sit on hardware in the field, so the relevant questions are where keys are held, whether a secure element is required, what happens to a rooted or cloned device, and how revocation works for a device that is not connected. A vendor who presents offline capability as having no security implications has not addressed the problem.
Can offline transactions be made final, or only queued?
Both models exist and they are not equivalent. A queued transaction is an instruction held until connectivity returns, so nothing has settled and the counterparty carries uncertainty. True offline settlement completes the transaction under pre-agreed limits, which is what a merchant accepting payment in an outage actually needs. Establish which one is on offer, because the word offline is used for both.
What limits should apply to offline transactions?
There is no universal figure, because the right limit is a function of the risk the institution will accept and the typical transaction size in the market. What matters is that limits exist and are stated: per transaction, per day, per account, and tightening as the time since last synchronisation grows. Adaptive limits based on customer history are stronger than fixed ones, and a vendor unable to express policy in numbers has not built an authorisation model.
Related
MobiBank is a Finnish financial technology company building a mobile banking platform for markets where connectivity and infrastructure cannot be assumed. This article is general information about platform evaluation and is not financial, legal or procurement advice. Certain capabilities described remain under development.