Why a banking app is not a normal app
For many customers in Tashkent and the regions, the mobile bank is the main way to deal with the bank: sending money to relatives, paying utilities, applying for a loan. That is why the project starts with a list of risks, not with design mockups. A bug in a food-delivery app is annoying. A bug in a banking app costs someone money and trust.
What sets these projects apart:
- a logic error can cost a customer real money;
- the app is a permanent target for fraud;
- activity is regulated by the Central Bank and personal data legislation;
- load is uneven, with peaks on salary days and holidays;
- the app must work with the core banking system and card processing.
Login, access and confirming operations
The baseline is a PIN or password combined with a one-time code or the device's biometrics. Fingerprint or face data is handled by the phone's operating system; the app itself does not store it. A new device should go through extra verification, and idle sessions should close automatically.
Confirmation screens deserve special care. A transfer or a change of personal details gets its own step, and the text states exactly what the customer is approving: the amount, the recipient, the action. A vague 'Confirm operation' message later turns into disputes and complaints.
Data protection and fraud prevention
On the technical side this means encryption in transit and at rest, server certificate pinning, detection of rooted or jailbroken devices, and protection of the code against analysis. Keys and secrets never sit inside the app, and card numbers or personal data stay out of logs and crash reports.
Still, customers usually lose money not because systems were hacked but because of social engineering: a call from a fake bank employee, a spoofed link in a messenger, a request to read out an SMS code. The app can help:
- warn before a transfer to an unfamiliar recipient;
- delay or double-check unusual operations;
- notify about every login and payment;
- offer a clearly visible card-block button;
- remind in the confirmation text that bank staff never ask for codes.
Reliability and integrations
A customer whose payment fails at the checkout remembers it for a long time. So the backend is built with spare capacity, real-time monitoring and on-call duty, and updates roll out gradually to a share of users first. If one service goes down, the rest should keep working. Idempotency matters too: pressing a button twice must not create a second transfer, and the customer must always see whether the operation went through.
The app is only the top of a large system: the core banking platform, card processing, national payment systems, credit scoring, CRM and notifications. Teams usually build an intermediate API layer that hides internal complexity and shields those systems from direct calls.
Regulation and the team you need
A bank must follow the requirements of the Central Bank of the Republic of Uzbekistan on information security and remote service, plus the personal data law, including the rule on storing data inside the country. The exact list should come from the bank's compliance and information security teams before design starts, not after the first version is built.
The team has to match: mobile developers, backend engineers, security specialists, QA and analysts. One freelancer is not enough for a project like this.
Interface and testing
Security should not make the app painful to use. A good banking interface shows the balance right after login, lets people repeat a frequent payment in a couple of taps, explains fees and timing before confirmation, and speaks clearly in both Uzbek and Russian.
Testing covers functional and regression checks across many devices, load tests that simulate peak days, independent penetration testing, and failure scenarios: what does the customer see when processing is unavailable? Launch is not the finish line either. A banking product keeps evolving and keeps being defended.
When a Telegram bot is enough
A full mobile bank is a job for a team with financial-sector experience. But many businesses in Uzbekistan need something simpler: a microfinance company, a shop selling in instalments, a school, a service business. For them a Telegram bot often covers the core: it collects applications, reminds customers about payments, sends a payment link through Click or Payme, and passes data to the CRM. The bot never collects card details; payment happens on the payment provider's side.
The principles match those of a bank: store as little data as possible, make confirmations clear, protect against double charges, and warn customers about scams. If your task looks more like this, markdev can help map the scenarios and build a Telegram bot around your process. Describe what you need and we will discuss where to start.
FAQ
Where does banking app development start?
With an audit of security requirements, architecture and regulatory constraints. The list of requirements should come from the bank's compliance and information security teams before design begins.
Can a single freelancer build a banking app?
A full banking app needs a team covering mobile and backend development, security, testing and analysis. A smaller service has a different scope, but security still cannot be left for later.
Where should customer data be stored?
The personal data law requires data of citizens to be stored inside the country. Confirm the exact requirements with a lawyer and your security team before starting.
Is a Telegram bot suitable for financial services?
For applications, reminders, status updates and payment links, yes. Card details should be processed by the payment provider, not by the bot.
Let’s look at your task for free
Leave your contact — in a 15-minute call we’ll show where leads get lost and what to fix first.