Banking App Design Trends Shaping UX in 2026

The banking app design trends that matter in 2026 are not the ones with the most AI in the press release. They are the ones that reduce a customer’s uncertainty at the exact moment it hurts: where is my payment, how much can I actually spend, what does this foreign amount mean, is this really my bank on the phone, and what do I do now that someone has emptied my account. Everything else is fashion. Some of it is expensive fashion. Some of it quietly breaks trust while the roadmap celebrates.

ANODA designs and audits financial products around the moments that decide whether customers trust them. The costumes change every season: skeuomorphic chequebooks, neobank pastels, gamified savings jars, and now a chatbot on every screen. The customer underneath has not changed at all. They want to know what is happening to their money, they want to fix it when it goes wrong, and they want a human when a machine cannot help. Most 2026 trend lists skip that part because it does not photograph well.

So this is not a mood board. It is a filter. For each trend we look at what changed, which customer job it touches, what it can make easier, where it fails, what it means for the interface, and the one question a team should answer before shipping it. It’s the same filter we use in our fintech and banking product design work. Some items on this list are genuine 2026 shifts. Others are old basics that too many banks still get wrong, and we label those honestly as baseline rather than dress them up as news.

What qualifies as a banking app design trend in 2026

A trend earns the name when three things are true at once. There is recent evidence that customers, regulators or the market have moved. The change alters the product experience, not just the marketing deck. And a bank can make a real adoption decision about it: build, test or skip.

Most things called “trends” fail one of those tests. A gradient that every fintech used this spring is visual fashion; it changes how the app looks and nothing about how the money behaves. A forecast that “open finance will transform banking” is an industry prediction; it tells a product team nothing about what to put on Tuesday’s release. A feature that three competitors launched is a rumour until someone can name the customer problem it solves.

Here is the working split we use when a client brings us a list of trends to evaluate:

The strongest trends of 2026 all do the same job from different angles. They explain the real state of the customer’s money and give them a safe next step. That is the lens for everything below.

A trend that doesn’t make a stressful money moment easier is a costume.

Durable trend or visual fashion: the ballet tutu test

Oksana Kovalchuk, ANODA’s founder, gets asked the same question in almost every fintech kick-off: should we just copy Revolut, Monzo or Wise? Her answer is yes, you can, and nobody should be ashamed of it. Samsung famously traced the iPhone. Copying a proven pattern is how most good products start.

The problem is copying without knowing why the pattern exists.

Copying a feature is not shameful. Copying it without understanding why it exists is dangerous. It’s like buying a ballet tutu because Masha has one, when you don’t dance ballet. What would it achieve?

A competitor’s feature was designed around their customers, their licence, their risk appetite, their support team and their data. Revolut’s spending analytics make sense inside Revolut’s product, with Revolut’s customer base of frequent travellers and multi-currency users. Paste the same screen into a regional bank whose customers mostly pay bills and check their salary, and you have bought a tutu for someone who goes to the gym.

This is keeping up with the Joneses, fintech edition. The feature arrives, the launch post goes out, and six months later the analytics show a screen nobody opens. The design and engineering budget is gone. Worse, every feature you add is one more thing the customer has to scroll past to find the one thing they came for.

The test before copying anything is short. What customer problem did the original solve, and do our customers have it? What does the feature need underneath: data, partners, a support process, a regulatory permission? What happens when it fails for our customer, not theirs? If the team cannot answer those three, it is not copying a trend. It is buying a costume.

Visual fashion that isn’t a banking trend

Every January someone publishes the season’s banking UI looks, and every year the list is mostly paint. It’s worth naming the usual suspects so nobody spends a quarter chasing them:

• Glass, blur and 3D cards. They photograph beautifully on Dribbble. On a real phone, translucent panels over a busy background cost contrast exactly where the balance sits. Use them where they help hierarchy, never behind numbers.
• Dark mode as a headline feature. It’s a setting customers expect, not a reason to switch banks. Ship it, test every state in it (held funds, warnings and error colours are where dark themes break) and stop putting it in press releases.
• Gamified saving. Streaks, badges and confetti can help a narrow group of savers. They feel patronising to an adult managing a mortgage, and grotesque to someone in arrears. Treat them as an audience decision, not a trend.
• Mascots and chatty copy. A friendly voice is fine until the customer is scared. The copy that works during fraud, a decline or a lost card is short, calm and specific. Write that first, then decide how much personality the happy path can afford.

None of this is wrong. It’s just not strategy. Fashion changes how the app looks in the store screenshots; trends change what the customer understands about their money. A redesign that updates the first and ignores the second is a fresh coat of paint on a house with no working doorbell.

Trend: AI assistants that resolve support jobs, not deflect them

This is the durable one, and also the one most banks are getting wrong in the most expensive way.

Start with the problem it should solve. Anyone who has tried to phone a bank to find out what happened to a payment deserves, in Oksana’s words, a monument made of gold; monks would envy that patience. Hold music, menu trees, a transfer to the wrong department, “your call is important to us”, and at the end, a person who can see less than the customer can see in the app. A useful assistant reads the customer’s own transactions, explains the payment state and handles routine questions, while people take over the cases that need judgment. That is how automation earns its place: solving the customer’s problem instead of hiding the support queue.

The scale of adoption is substantial. Bank of America reported in March 2026 that 20.6 million users interacted with Erica nearly 700 million times in 2025, with more than 3.2 billion interactions since launch. The European Banking Authority’s September 2025 factsheet reports AI deployment at 92% of EU banks it observes. The next competitive question is quality: can your assistant finish the job and bring in a person when it cannot?

Now the failure mode. In 2023 the US Consumer Financial Protection Bureau published a report on chatbots in consumer finance and gave the problem a name that stuck: the “doom loop”. The customer asks a real question, the bot answers a different one, offers a menu, repeats itself and never hands over to a human. The CFPB was blunt that deploying chatbots that give inaccurate information or block access to a person can break consumer-protection law. That is not a UX nitpick. It is a legal and reputational liability wearing a friendly avatar.

Oksana’s version is shorter:

The danger is that the AI can be unbelievably stupid. Everything it says is: “Hello, thank you for contacting us, here’s an article on how to open a card.” And then you’re on your own.

That scripted article-recommender is the chatbot equivalent of a receptionist who hands you a leaflet and locks the door. It lowers the support queue on the dashboard and raises the number of people who leave for a competitor. The cost is hidden because nobody measures the customers who closed the chat and quietly moved their salary elsewhere.

Klarna is the case study everyone should read before launching an assistant. In its 27 February 2024 release, Klarna reported that its AI assistant handled two-thirds of customer service chats in its first month and described the workload as equivalent to 700 full-time agents. Bloomberg News reported on 8 May 2025 that CEO Sebastian Siemiatkowski considered the customer-service cost-cutting push excessive and was planning recruitment to preserve access to human support. A fast answer is worthless if it is the wrong answer, and a cheap support channel is expensive if customers leave through it.

What separates a useful assistant from a faster dead end is not the model. It is the design around it:

• It knows the customer’s actual data. “Where is my payment” is answered with that payment, its status and its expected arrival, not with a help-centre article.
• It states its limits. “I can open a trace, I can’t cancel it, it has already left your account” is worth more than a confident wrong answer.
• It hands over with context. The person who picks up sees the conversation and the account state. Nobody asks the customer to repeat everything.
• It never pretends to be the last door. “Talk to a person” is visible from the first message, not unlocked after three failed attempts.

NatWest’s September 2026 announcement described a fraud triage agent inside its Cora assistant that routes customers to human fraud, scam and dispute teams, and it reported that 81% of survey respondents say access to a real person is the most important factor in trust in AI use in financial services. The assistant is the front desk, not the whole building.

Trend: AI where money and trust are at stake needs a smaller job, not a bigger model

The second AI trend of 2026 is less glamorous and more important: banks are learning where not to put AI.

Oksana’s view is direct. In 2026 everyone started bolting AI onto everything, and fintech and healthcare are the two most dangerous places to do it without discrimination. A language model does not take responsibility for the accuracy of what it says. A wrong answer about a recipe is funny. A wrong answer about whether a payment can be reversed, whether a loan affects a credit file or whether a fee applies costs the customer money and costs the bank a complaint, a remediation bill and possibly a regulator’s letter.

Customers know this, and they are nervous about something else too. Training models is expensive, everyone knows it, and many customers now assume that their financial data is feeding someone’s model. Whether that is true for your bank or not, silence on the question reads as a yes.

Regulation is catching up in the same direction. The EU AI Act lists AI systems that evaluate a person’s creditworthiness or set their credit score as high-risk. The European Commission’s current AI Act timeline places the application of Annex III high-risk rules on 2 December 2027 following the AI Omnibus, but the direction has not changed, and the transparency duties for AI that talks to people still apply from August 2026. For a product team that means a practical rule: the closer the AI gets to a decision about someone’s money, the more it needs a clear scope, a human in the loop and an explanation the customer can read.

The design implication is a boundary the customer can see:

• What the assistant can see. Transactions, card status, the account in front of you. Named, not implied.
• What it can do. Answer, explain, freeze a card on request. Anything that moves money waits for the customer’s confirmation.
• What it never does. Moves money on its own, makes lending decisions, shares conversations with marketing.
• What happens to the data. If chats are used to improve the service, say so, and let customers opt out without digging through a privacy policy.

This is also where we tell clients to keep the assistant boring. It does not need a personality, a name with a pun in it or an animated face. It needs to be right, to know when it isn’t, and to hand over quickly. A model that tries to be charming about someone’s overdraft is a clown at a funeral.

Trend: offers that read the customer’s situation instead of shouting at everyone

Banks have always sold products inside the app. What is changing is how. The old model is a full-width banner shown to every customer and the hundred-and-first promotional email. The new one reacts to what the customer is actually doing: a travel card offered to someone who just paid for flights, an overdraft buffer explained to someone who dipped below zero twice this month, nothing at all offered to someone in the middle of a fraud case.

Oksana is careful to separate the two ideas people blur together. Behaviour-based offers are not magic AI. They are smarter marketing: stop offering everything to everyone. AI can help interpret what customers are asking for and bring a relevant product into the conversation. The offer still needs to fit the customer’s situation, with a clear way to decline it. But the principle works without any model at all.

The principle has a sharp edge, and she put it better than any framework:

Don’t offer a savings bonus to a person who is ten thousand in debt on a credit card. It looks like mockery, and it only makes them angry.

That is adding insult to injury, and it happens every day because the offer engine and the account state live in different teams. Marketing owns the banner, the product team owns the balance, and nobody owns the moment where they meet on the customer’s screen. It is like a gym selling annual memberships at the hospital exit to a patient on crutches. Technically a qualified lead. Practically an insult with a price tag.

The design implication is not “personalise more”. It is “personalise responsibly”:

• Check the state before the offer. Arrears, recent fraud, a disputed payment, a hardship flag or a declined card are all reasons to show nothing, or to show help instead of a product.
• Offer the product that answers the current problem. Someone paying heavy interest may genuinely benefit from a repayment plan or a balance transfer explained honestly. That is useful. A savings bonus is not.
• Make “not now” work. One tap dismisses the offer and it stays dismissed. An offer that returns every session is spam with a login.
• Explain why you’re seeing it. State the permitted signal behind the offer, and let the customer dismiss it or manage personalisation. Make the reason understandable and the customer’s controls easy to find.

Use the bank’s actual interest calculation and repayment terms in the implemented offer: eligibility, rate, fees, duration and total repayment. The illustration shows the design principle — help that starts from the customer’s balance.

Personalisation should feel like service, not surveillance. Use permitted account context, explain the reason for the offer and put the customer in control. Keep sensitive details out of shared screens and notification previews.

Trend: sentiment-aware service for customers who have run out of patience

Here is a trend nobody puts on a slide because it isn’t a feature: customers are angrier than they used to be, and they say so.

Oksana’s observation from years of reading support logs and user research is that people are overloaded and running on empty, and they no longer hold back in words or emotions. Rage-quitting a checkout, rage-buying from a competitor, typing in capitals at a chatbot: the threshold has dropped. Products have to adapt to the customer they actually have, especially when a banking problem brings that frustration to the surface.

For a bank, that customer is often at their worst exactly when they contact you. They are not browsing. Their card was declined at a till, their rent didn’t arrive, or money has vanished. A script that answers “WHERE IS MY MONEY” with “I’m sorry, I didn’t understand that, please rephrase” is a waiter reading out today’s specials to a table that is on fire.

Sentiment-aware design means the product notices frustration and changes its behaviour:

• Signals. Repeated failed attempts, the same question asked three ways, capitals and strong language, a declined payment followed by a support visit, a long session on the help screens.
• Responses. Skip the script and go straight to the most likely answer. Offer a person sooner. Drop marketing and cheerful copy for the rest of the session. Keep the language short and specific.
• Limits. Detecting emotion is a signal to help, never a reason to profile, deprioritise or upsell. A customer who swore at the bot should reach a human faster, not land on a “difficult customers” list.

This is where AI earns its place: understanding messy customer language and getting the right person involved sooner, with the context attached. Train and review that routing on your own support conversations, and keep a direct human route open. A longer automated apology is no substitute for help.

Trend: explainable balances, holds and “what happens if I spend this”

If one change from this list would prevent the most angry calls, it is this one. And it is not new technology. It is honesty about a number.

Card payments are rarely final when they happen. A hotel reserves a deposit at check-in. A fuel pump pre-authorises more than the fill-up; PNC’s own guidance uses the example of a $100 hold for a $50 tank. A car rental may reserve a security amount; the amount and release timing depend on the provider, transaction and bank. The money is still technically in the account, but it can’t be spent. Many apps still show a single balance number that silently mixes all of this together, or worse, shows the full amount as if the hold doesn’t exist.

Oksana described what that feels like from the customer’s side, and it is worth reading slowly:

Money is placed on hold, and the app still shows it as available. I spend more, and more, and more, I go over budget, and then I have an overdraft on a debit card. Processing has been fixable for years. Show it clearly: this much is available, this much is on hold. If you spend more now, you will go below zero. It’s not free money.

The CFPB’s 2022 circular described “authorize positive, settle negative” transactions: funds cover a debit-card payment at authorisation, but intervening transactions or settlement processes leave an insufficient balance when it settles. The bureau withdrew Circular 2022-06 on 12 May 2025, so its historical unfairness analysis should not be presented as current guidance. The design question remains concrete: explain authorisation, available funds and settlement without implying that a displayed balance guarantees the absence of later fees. Confirm applicable account terms and current legal requirements separately.

The interface work has three parts. Whether the existing system can support them depends on access to current available-balance, hold and settlement data; confirm those dependencies with the banking and engineering teams.

First, distinguish available and held money on the home screen using the bank’s defined balance states. Make the spendable amount prominent when it is reliably available, and explain its calculation and update time. Show missing or stale data explicitly rather than presenting an estimate as confirmed spendable funds. The held amount sits next to it with the reason. The full account balance is still there for anyone who wants it, one line down.

Second, explain each hold where the customer finds it: the reserved amount, reason, known transaction state and available support route. Label settlement and release dates as estimates when they are not confirmed, identify the source of the estimate, and show unknown timing explicitly. Reconcile partial settlement, reversed authorisation and released holds so the same amount is not counted twice.

The dates, final bill and 3–5 working-day release window shown here are illustrative assumptions. A real hold detail should use the applicable bank and merchant information, distinguish an expected date from a confirmed event, and avoid promising a release deadline without a reliable basis.

Third, warn before a foreseeable consequence using the bank’s available data. Distinguish a confirmed scheduled payment from a forecast, show the assumptions and update time, and allow for intervening credits, payments and changes in the final merchant amount. Explain a potential shortfall without presenting a forecast as a guaranteed overdraft or fee.

The evidence here is refreshingly concrete. Count overdraft fees charged within a few days of a hold settling, complaints that mention “pending” or “available”, and support contacts that start on a transaction screen. If those questions recur, the balance experience deserves attention: it is costing the bank agent time and customer confidence.

For the full treatment of balances, payment states and what a transaction list should say, our guide to banking app UX patterns for trust and security goes deeper. Here the point is narrower: in 2026, a balance that hides held money is no longer an old habit. It is a choice.

Trend: travel-aware money, because ₩20,000 feels like Monopoly money

International travel came back hard after the pandemic, and with it an old problem that banking apps have never quite solved: spending in a currency your brain can’t feel.

Oksana’s example is the one every traveller recognises:

When I travel in Japan or Korea, I don’t understand how much I’m spending. It says: “You spent 20,000 won.” It looks like Monopoly money, so I think, fine, let’s spend more. I don’t want to do the maths. You’re the banking app. You do the maths.

When the bank has reliable transaction and currency data, the interface can provide home-currency context. Distinguish an indicative conversion from the final posted amount, identify the rate and time used, and explain applicable fees. Show incomplete or delayed spending data explicitly rather than implying that the day’s total is complete.

In the implemented notification, use the applicable card terms and current rate, identify estimated amounts and respect the customer’s financial-preview settings.

Travel-aware design does three things:

• Provides home-currency context where useful, distinguishing indicative and posted amounts. Show the rate source, timestamp and applicable fees in the detail screen. Let customers control whether financial amounts and merchant details appear in notification previews.
• Adds understandable spending context, such as recorded spending or a budget the customer set. Define which transactions are included, identify pending amounts and late updates, and test whether the intended audience can interpret the information.
• Prepares the customer for the choices at the till and the ATM. Card terminals and cash machines abroad often offer to charge in the customer’s home currency at their own rate, a practice called dynamic currency conversion. Visa’s DCC guidance requires participating merchants and ATMs to display both currency amounts, the exchange rate and additional fees or markup, and to let the cardholder accept or decline conversion without choosing for them. For covered payments in the EU, Article 4 of Regulation (EU) 2021/1230 sets the disclosure framework for conversion charges as a percentage markup over the latest available ECB euro reference rates. Confirm the payment, currency and provider scope before treating that requirement as applicable to a particular journey. Explain the difference between the card issuer’s conversion and the merchant or ATM’s conversion before the trip. Show the applicable rate and fees so the customer can compare the actual options.

Foreign-currency holds can add another layer of uncertainty. Hotels, car rentals and fuel purchases may use pre-authorisation; the reserved and final amounts can differ because of the merchant charge, conversion timing or applicable fees. Explain those states using the bank’s actual transaction data rather than assuming a single cause for every difference.

Trend: in-app messages and approvals replace the SMS

Oksana’s wish here is blunt: the baseline should be to stop sending those awful SMS messages and communicate through the app with push notifications. There are good reasons behind the frustration, and they are no longer just about taste.

An SMS one-time code is a string of six digits with no context. It doesn’t say what it approves, how much, to whom or from which device. That is exactly why scammers love it: “Hi, it’s your bank, we’ve sent you a code to stop the fraud, can you read it back to me?” The customer reads out the code, and the code authorises the fraud. Postcards are fine for holiday greetings. Nobody should approve a £1,249 payment with one.

The scope matters. MAS and the Association of Banks in Singapore announced in July 2024 that major retail banks would progressively phase out OTPs for account login by customers using digital tokens. That announcement concerns login for that customer group; it is not a worldwide prohibition of SMS or a rule for every payment approval. For the product team, select the permitted authentication mechanism with the security team and make the action being authorised clear in the interface.

In-app approval changes the question from “type this code” to “do you want to pay this merchant this amount now?”. The customer sees what they are agreeing to. The “this wasn’t me” button is one tap from the approval, not a phone number in the small print. Use a warning that matches the bank’s actual process, such as never approving a payment at an unsolicited caller’s request. Test whether customers understand the warning under pressure; wording alone does not prevent fraud.

Two cautions. First, push is only as good as the words inside it. A push notification that says “Action required” and nothing else trains customers to tap whatever appears. Second, in-app approval does not make a product secure on its own; it moves the moment of decision to a place where the product can explain it. A notification that identifies the merchant, amount and request helps the customer evaluate the action. Its fraud-prevention effect still depends on the authentication flow, delivery and customer response.

Approval flows also need explicit states for an expired request, a lost connection, an unavailable biometric check and a customer who has lost the enrolled phone. Keep the merchant, amount and request identity attached to the decision; refresh an expired request instead of silently approving it. Show the approved recovery route when the device is unavailable, and keep sensitive payment details out of lock-screen previews unless the customer has chosen to show them.

The same logic applies to messages. A secure in-app inbox, where the bank’s letters, dispute updates and security notices live, gives customers one place where they know the bank really speaks. Anything that arrives by SMS or email can then say “we’ve sent you a message in the app” instead of carrying a link, and customers can be taught a simple rule: the bank never sends links to sign in. It’s a small habit with a big effect on phishing, because the scam depends on the customer not knowing where genuine messages live.

Real-time alerts belong to the same trend. Customers expect to know about a card payment the moment it happens, especially abroad or late at night. The design work is in deciding what deserves an interruption: a large payment, a new device, a changed phone number, a failed login from another country. Not every coffee.

Trend: recognisable bank communication and customer code words

Impersonation scams can persuade customers to initiate a transfer themselves: someone calls pretending to be the bank’s fraud team, and the customer, frightened and trying to protect their money, moves it to a “safe account”.

Oksana calls communication through secret words a wonderful trend that banks should keep developing, and there are two mechanisms worth distinguishing. Do not confuse customer authentication with verification of an incoming caller. Fulton Bank’s security word authenticates customers contacting its call center; it is not evidence that an incoming caller is genuine. A separate mechanism is in-app call status. Monzo described a call-status feature in 2023 that shows in the app whether its team is on the phone with you, and by January 2026 Which? reported that Nationwide had launched a call checker, with Starling, Revolut and Barclays running similar tools.

The useful design principle is a trusted confirmation route the customer opens independently. A familiar voice or knowledge of personal details is not enough to establish who is calling.

The design details decide whether this works under pressure:

• Make call status clear and current. Show confirmed calling status only when the bank has reliable data. If the status is unavailable or stale, say that the call cannot be verified and provide an independently initiated contact route; do not turn missing data into a false assurance.
• Keep customer authentication secrets separate from caller verification. Explain the bank’s approved process and use an independently opened app or a trusted contact route to verify a doubtful call. A customer security word must not be presented as proof that an unsolicited caller is genuine.
• An unverified call comes with appropriate actions. End the call, contact the bank through a trusted route and report suspected impersonation. Offer account or card restrictions when the bank’s process and the suspected exposure warrant them.
• The feature is easy to find while on a call. If it’s four menus deep, it doesn’t exist for someone whose heart is pounding.

Baseline, not trend: biometrics, document checks and two-factor authentication

Now the part that shouldn’t be on a 2026 trend list at all, and is here only because too many products still treat it as news.

Biometric sign-in, document verification and multi-factor authentication are established capabilities, but the permitted onboarding route depends on the market, account and customer. India’s UIDAI publishes substantial Aadhaar authentication and e-KYC activity. Nigeria’s Central Bank explains BVN and NIN requirements, including electronic retrieval of identity information for onboarding. Digital identity infrastructure is widespread, and the app should make the supported route easy to understand. Design the permitted digital route clearly, explain why additional verification is needed, and give customers who cannot use it a workable alternative.

Two-factor authentication was once a selling point. Now, in Oksana’s words, it should simply be the default state. Passkeys are an established implementation option: ABANCA reported on 23 April 2025 that more than 42% of its mobile-banking users used Llave ABANCA to confirm operations in the app. It shows how a stronger authentication experience can become part of everyday banking.

But there are two traps in treating these as solved.

First, security friction is not proof of security. Six prompts, three codes and a selfie for a £10 transfer to a regular payee don’t make the account safer; they teach customers to click through prompts without reading, which is precisely the habit fraudsters exploit. Match the friction to the risk: quick and familiar for routine actions, step-up checks for a new payee, a large amount, a new device or changed contact details, with a sentence explaining why.

Second, none of these on its own makes a product secure. Two-factor authentication doesn’t help when the customer is persuaded to approve the fraudster’s payment. Biometrics don’t help when the account recovery flow can be social-engineered. The strength of the lock matters less than the strength of the process around it. That makes account recovery part of the security review.

Trend: account and card recovery that doesn’t punish the victim twice

Security has genuinely improved in the last few years. Recovery still leaves customers fighting the product when they most need help.

Oksana’s description of what happens after fraud is the most important paragraph in her interview, so here it is almost word for word. Account security has been raised to a higher level, but if you’re already a victim, you already feel terrible and your money has already been stolen, the bank finishes you off, and the app finishes you off too, because it’s unclear what to do. Recovering a card or regaining access to an account currently takes a series of circles of hell.

Think of a hospital emergency room that makes a bleeding patient fill in a registration form before anyone looks at the wound. Every step is justified on its own: we need to know who you are, we need to check your history, we need a reference number. Together they are cruelty with a process map. That is kicking someone when they’re down, and customers remember it longer than they remember the fraud itself.

In the UK, APP fraud reimbursement protections apply to eligible UK transfers through Faster Payments or CHAPS made from 7 October 2024, with a maximum claim of £85,000. The PSR said this limit would cover 99.8% of Faster Payments APP scam cases by volume that fall within the policy. Customers need the app to make eligibility, claim progress and the next step clear.

A recovery flow a victim can survive answers four questions on the first screen:

• What is protected, and what is still under review? Show the confirmed card and account restrictions first. State which actions are blocked and which remain possible; do not promise that all remaining funds are safe unless the bank has established that.
• What happens next, and how long does each step take? A timeline with honest estimates beats “we’ll be in touch”.
• What can I do right now? A virtual card for the week, access to salary, a way to pay rent. Life doesn’t pause for an investigation.
• Can I talk to a person? Yes, from this screen, without repeating the story three times.

Card recovery follows the same logic on a smaller scale: freeze in one tap, request a replacement in the same flow, show whether a virtual card is available, and explain which recurring payments can be updated through the network. The customer should never have to choose between security and buying groceries this week.

Trend: payee name checks before the money leaves

This one is genuinely time-sensitive, because regulation has just changed the experience in a large part of Europe.

In the UK, Confirmation of Payee has checked the account holder’s name against the details a customer types for years; by October 2024 nearly all Faster Payments and CHAPS transactions were covered, with more than two million checks a day. For euro credit transfers covered by the EU Instant Payments Regulation, the ECB lists Verification of Payee deadlines of 9 October 2025 in euro-area member states and 9 July 2027 in non-euro-area member states. The check applies to both standard and instant credit transfers. The payer receives a match, close match, no match or other result before initiating the payment.

That is a design problem disguised as compliance. The result appears at the most tense moment in the journey, just before the customer presses send, and the wording decides whether it prevents fraud or just adds a scary screen people learn to dismiss. It’s the courier at your door with a parcel addressed to your street and someone else’s name: the useful question isn’t “are you sure?”, it’s “do you know A. Webber?”.

Good payee checks distinguish match, close match, no match and unavailable. Show a suggested name only when the verification service returns it and the applicable scheme permits disclosure. Explain what to do in each case in one sentence. They make stopping as easy as continuing. And they are honest when the check couldn’t run, rather than silently letting the payment through or blocking it with no explanation.

Trend: cross-channel continuity, so the customer never starts from zero

A customer asks the assistant about a payment, gives up and calls. The phone agent asks for the same details. The agent transfers them to a specialist, who asks again. Then the customer visits a branch, and the branch can’t see the call. Every channel works. The customer’s problem falls through the gaps between them.

Continuity is the trend that makes the others work. The assistant hands over with the conversation attached. The phone agent sees what the customer was looking at in the app when they pressed “call us”. A dispute started in chat can be finished in the app without a new reference number. A notification opens the exact screen it talks about, not the home screen.

It’s a relay race where each runner insists on starting their lap from the starting line. Every leg is fast. The team still loses.

The design deliverable here isn’t a screen, it’s a shared case: one record of the customer’s problem, with status and history available to authorised staff in the channels that need it. Without it, every assistant, every call-back feature and every in-app chat is another place for the customer to repeat themselves.

Overrated: the bank that thinks it can run your whole financial life

Every few years a banking trend promises that the bank app will become the customer’s complete financial assistant: budgets, insights, subscriptions, savings goals, forecasts. In 2026 the pitch comes with AI attached. Some of it is useful. The promise of completeness is not.

Oksana recently spoke to a founder who was ready to close his personal-finance app. He was afraid that banks rolling out budgeting and spending insights would squeeze him out of the market. Her answer calmed him down, and it’s the reality check every bank product team should hear:

The bank shows only its own cards and its own reports. I have three different cards in three banks in two countries. That’s where a single bank’s help with organising my finances ends.

A spending insight built on one account out of three can mislead if it presents that account as the customer’s complete financial picture. “You’re on track, you spent 18% less this month” is meaningless if the customer moved their groceries to another card. Worse, it can mislead: the customer relaxes because the app says they’re fine.

The honest design options are limited, and that’s fine:

• Say what the insight covers. “This only counts your Alder accounts” is a sentence, not a failure.
• Aggregate only with explicit, revocable consent. Where supported and permitted, connecting other accounts can broaden coverage. For this spending-insight use case, request only the necessary read access, explain supported accounts, missing data and refresh delays, and make consent and disconnection clear. Show the coverage clearly so customers know which accounts are included.
• Don’t celebrate a partial number. Congratulations based on a third of the picture teach customers to distrust every insight that follows.

For independent personal-finance products, this is good news: the multi-bank, multi-country customer still needs them. For banks, it means spending insights are a useful feature for their own accounts, not a reason to promise more than the data allows.

Baseline with a deadline: inclusive and adaptive interfaces

The European Accessibility Act applies from 28 June 2025 to covered consumer banking services, including their websites and mobile apps. Its scope includes exemptions and transitional provisions, so the product team should confirm the applicable requirements for its service. For covered interfaces, screen-reader support, text scaling and alternatives to colour-only communication belong in release acceptance criteria.

The trend worth watching is adaptation rather than a separate “accessible version”. The same app adjusts to larger text without breaking the layout, supports simplified modes for customers who find the full product overwhelming, and keeps critical actions such as recovery, freezing a card and reaching a person reachable in every mode. It’s the difference between a lift that works for everyone and a ramp bolted on round the back. Our guide to accessibility in UX design goes deeper; here the point is timing. Check the applicable deadline and make accessibility part of the current release plan.

From a trend to a coherent financial product: Blackstar

In our Blackstar investment app redesign, the concrete task was to help first-time and experienced investors navigate one product. Active Invest and Auto Invest needed distinct entry points; Ghana’s mobile money and treasury bills needed to sit alongside global stocks and ETFs. We redesigned onboarding, markets, the wallet and portfolio analytics, with light and dark interfaces on one design system, then extended the work to a responsive website and brand book.

The connection to banking UX is the design problem: make different financial choices understandable without fragmenting the experience. Blackstar is an investment product, so this case supports investment navigation and interface consistency. Our designs, prototypes and specifications gave the client’s developers a coherent product to implement. See our investment platform design service for work on portfolios, funding and investment journeys.

Design systems and security review for multi-product banks

Banks rarely have one app. They have retail, business, cards, savings, lending, an investment wing, a web banking portal, and a new product every year that was launched by a separate team with its own designer and its own idea of what a “pending” badge looks like. Every new trend multiplies across all of them.

When a new pattern arrives, such as an assistant entry point, an in-app approval, a held-funds breakdown or a trusted call-status check, it has to look and behave the same everywhere. Otherwise customers learn that the same word means different things in different corners of the same bank, which is exactly the confusion fraudsters use. Traffic signs work because a stop sign looks the same in every town. A bank whose “approve” button looks different in each product is a country where every town designed its own.

That is the job of a design system in a regulated ecosystem: not a library of pretty components, but a governed set of patterns for money states, security prompts, alerts and recovery, with content rules and review built in. When the fraud team changes a warning, track its review and adoption across the relevant products; keep each product on the agreed version so the same warning reaches the customer everywhere.

The most dangerous trend of 2026: vibe-coded delivery on financial data

If there is one trend Oksana would ban from banking roadmaps, it isn’t a feature. It’s a way of building.

The banking trend most likely to destroy trust is AI shoved in without discrimination. And vibe coding without thinking, where you get hacked in 24 hours and your users’ data is sold all over the internet. That’s the worst trend there is.

Vibe coding means generating working code with AI quickly, accepting what looks right and shipping it without the review a financial product needs. For a prototype, it’s a superpower. For a flow that touches identity documents, balances or payments, it’s a vault door ordered online and installed over a weekend by an enthusiastic nephew. It looks like a vault door. Nobody checked the hinges.

Security review should include third-party data flows as well as application code. In its September 2026 incident notice, DriveWealth states that unauthorised network access occurred on 4–5 September and that personal information was exfiltrated. For the product team, map which providers receive customer information, verify access and disclosure controls, and define the incident and customer-support routes before release.

Oksana’s operating recommendation for fast-moving banking products is a UX audit and a security audit every three months, covering all critical flows. That’s her practice advice, not a regulatory standard, and some teams will need a different rhythm. The logic behind it is simple. A banking product that ships every two weeks changes more in a quarter than an old bank changed in a year. You don’t service a car only after the wheel comes off.

Where these trends make or lose money

Trend articles rarely talk about money, which is odd, because every item above shows up on a bank’s P&L.

Unclear balances and holds cost overdraft refunds, complaint handling and regulatory attention. Every “where is my payment” question that reaches a phone line instead of being answered in the app costs agent time, and every one that ends in a doom loop costs a customer who took years and a large marketing budget to acquire. Recovery flows that punish fraud victims turn a reimbursable loss into a closed account and a one-star review that sits at the top of the app store for a year. Offers that mock people in debt don’t just fail to convert; they get screenshotted.

Start by checking the data and integration already available. Explaining a hold or translating a foreign amount may mainly need content and interface work; payee checks and trusted call status also need the relevant verification services and operational controls. Prioritise the changes that address frequent customer problems with the smallest confirmed implementation scope. The expensive trends, AI assistants and cross-bank insights, can pay back too, but only when they finish the job. An assistant that deflects half the questions and loses a tenth of the people who ask them is not a cost saving. It’s a slow leak with a nice dashboard.

How to validate a banking trend before rollout

Everything above comes down to five questions a team should answer before any trend reaches the roadmap. If a cell stays empty, that’s the answer.

1. Which customer problem does it solve, and where is the evidence? Support tickets, complaints, session recordings, research sessions. Not competitor screenshots.
2. Which state of the customer’s money does it make clearer? Available versus held, where a payment is, what a foreign amount costs, whether a call is genuine. If the answer is “none”, it’s marketing.
3. What data does it need, and where is the boundary? What it reads, what it can do, what it never does, and whether the customer can see that in the app.
4. What happens when it fails? The wrong answer, the false alarm, the locked account, the offer shown at the worst moment. Every trend needs a designed failure state and a route to a person.
5. How will we know it worked? Fewer “where is my money” contacts, fewer overdraft complaints after holds, faster recovery times, fewer scam losses. Measured against a baseline, not a launch-day screenshot.

Then test it the way customers will meet it. Not in a quiet usability lab with a relaxed participant on a good day, but with realistic stress: a declined card at a till, a hold that ate the rent, a call from “the bank”. Test the recovery path, not just the happy path. Test on a mid-range phone with large text. Test in the customer’s second language if a large share of your customers use one.

Roll out gradually, starting with the customers most likely to benefit and least likely to be hurt, and watch complaints and support contacts as closely as feature usage. A trend that increases engagement and complaints at the same time is not a success.

Banking app design trends: controls to assess before rollout

Put trust at the centre of prioritisation. The highest-stakes journeys need more than a polished screen: accurate money states, clear permissions and a recovery path that works. Use these priorities to decide where your design and engineering effort will protect customers most.

Prioritise frequent customer problems using the confirmed data, partner and operational requirements. The balance screen, the hold, the foreign amount and the recovery flow deserve explicit acceptance criteria alongside new features.

What to take into your 2026 roadmap

Copying a feature isn’t shameful. Copying it without knowing why it exists is. A durable banking trend makes a stressful financial task easier, shows the real state of the customer’s money, keeps a safe path to a human and survives security scrutiny. AI assistance, contextual offers and richer automation can belong on the roadmap, but only with a bounded job, transparent data use, human escalation and a designed recovery path. If the team can’t define those controls, the modern-looking feature isn’t a trend. It’s a trust liability with a launch date.

Why ANODA looks beyond the banking trend list

A new feature cannot repair a broken relationship with the customer. ANODA connects the financial task, the interface states and the business consequence: the balance people act on, the payment they cannot explain, the handoff that fails and the recovery journey they dread. Our Blackstar work shows how we turn complex financial choices into a coherent design system and a developer-ready product.

You get a banking experience that explains what matters, makes the next action clear and treats trust as part of the product. That is more valuable than another fashionable screen your support team has to explain.