What makes financial products different
In most services, a bug can be quietly fixed in the next update. In a financial product, a bug means the wrong amount in someone's account, and you'll have to explain it to the customer, the partner bank and sometimes the regulator. That's why more time goes into logic design and testing than into the interface.
The second difference is dependence on partners. Banks, payment providers and identity verification services have their own rules, limits and response times. The product must behave correctly even when one of them is slow or returns an error.
Common goals of financial businesses
- Launch a new product: a wallet, a money transfer service, a credit line or a personal finance app.
- Move customers online, so they handle most transactions themselves without visiting a branch or calling.
- Shorten the path from application to decision in lending without losing control over risk.
- Give support and finance teams convenient tools to investigate transactions without asking developers.
- Modernize an outdated app that's hard to develop and that customers rate lower than competitors' apps.
What we build
Wallets and payment services with top-ups, transfers, bill payments, transaction history and notifications for every movement of funds.
Mobile and online banking for customers of banks and financial companies: accounts, cards, statements, template payments, limit and security management.
Lending platforms: calculator and application, data sent to scoring services, decision, loan agreement, repayment schedule and payment reminders.
Internal dashboards for support agents, risk managers and accounting: customer and transaction search, manual reviews, reports, audit log.
Personal finance products: expense tracking, savings, and spending analytics from bank accounts where the bank provides access.
Transaction accuracy
The foundation of any financial product is the transaction ledger. We design it so the balance can always be explained by the history of entries, rather than just storing the current amount.
- A repeated button tap or a duplicate request from a provider doesn't create a second charge.
- Every transaction has a clear status: created, processing, succeeded, declined, refunded.
- Product data is regularly reconciled with bank or payment provider data, and discrepancies are routed to the responsible team member.
- Every manual operator action is logged: who changed what and when.
Customer verification and regulatory requirements
Most financial products require customer verification: identity checks, screening against risk lists and suspicious activity monitoring. This is usually done through specialized KYC and AML services, and our job is to build verification into the product so legitimate customers get through it without extra effort.
Licensing, rules for handling customer funds and reporting requirements are the responsibility of your company and your legal counsel. We take these requirements into account during design, but we don't assess the product's legal compliance. If the product works with payment card data, it's usually simpler to have a payment provider process it than to store it in your own system.
An interface that doesn't intimidate
Financial transactions cause anxiety even when everything is fine. People want to see exactly how much will be charged, what the fee is and when the money will reach the recipient. We show this information before confirmation, not after.
Error messages need special attention. Instead of “Something went wrong,” users should see what happened to their money and what to do next: retry, wait or contact support. It's also important that the app is easy to use for older adults and people using financial services on a phone for the first time: large fonts, clear labels and minimal jargon.
Security and access
We address data protection requirements from the very first stage: encrypted connections, role-based staff permissions, confirmation of important actions with an additional code and limits on login attempts. Only those who truly need access to real customer data for their work have it.
For high-risk products, we recommend an independent security review before launch. Our general approach is described on the security and technical audit page.
Typical integrations
- Banks and card processors for accounts, cards and transfers.
- Payment providers such as Stripe or PayPal, as well as Apple Pay and Google Pay.
- Identity verification and credit scoring services.
- CRM and support systems, so an agent sees the customer's history in one window.
- Accounting systems and data warehouses for reporting and analytics.
Every integration is not just a connection but also a failure plan: what the user sees when a partner is unavailable, and how the transaction completes once the connection is restored.
Portfolio examples
Promodex projects in finance include Idram, MyAmeria, Telcell Wallet and My Viva. With financial products, we first map out money flows and error scenarios, and only then move on to screen design.
What affects the cost
- Product type: a single payment flow or a full-featured wallet with transfers, currencies and cards.
- Number of partners: how many banks, providers and verification services need to be integrated.
- Platforms: web only, mobile app only, or both plus an operator dashboard.
- Verification and reporting requirements: what exactly must be built into the product under your license.
- State of the existing system: if we take over someone else's product, a code and data audit comes first.
We estimate in phases: first a description of the logic and architecture, then development by priority.
FAQ
Can we start with a smaller version of the product? Yes, and it's often the right call. The first version can cover one core flow, such as transfers, with the rest added after validating demand.
Will you help us get a license? No, that's a job for lawyers. We can prepare a technical description of the product that you'll need when dealing with the regulator or a partner bank.
Do you work with existing financial systems? Yes. We first dig into the code, data and integrations, then recommend what to develop further and what is safer to rebuild.
Who will support the product after launch? We can stay on for ongoing support and feature development, or hand the product over to your team with documentation.
Why Promodex
Promodex has been building digital products since 2015 — 750+ projects in total. Financial products are handled by our in-house team of designers and mobile and web developers, with no parts of the work outsourced. We openly discuss what we're doing and why, and after launch we stay with the product as new partners, currencies or requirements come along.