A customer using a new phone may need an extra identity check. Repeated attempts to use stolen passwords call for a different response. Financial firms need to assess both without making everyday banking harder.
Controls should distinguish suspicious activity from routine account use, then respond in proportion to the evidence. That means considering the harm an action could cause and the consequences of blocking a genuine customer.
Spot the patterns behind suspicious activity
Automated attacks use the same login pages, application forms and payment services as customers. Knowing the warning signs at each point helps your team decide what to investigate.
Login attempts. Credential stuffing tests username-and-password pairs exposed in a breach against another service, as OWASP explains in its prevention guidance. Attackers replay credentials that worked elsewhere. If they gain unauthorized access to an existing account, that is account takeover. Warning signs include a burst of failed logins across multiple accounts from few devices, or successful logins followed immediately by attempts to change contact details. These patterns warrant investigation, even when individual requests look ordinary.
Account applications. OWASP lists fake-account creation at signup pages as a distinct category of automated abuse. A form that checks only whether fields are filled may allow scripts to submit fraudulent applications. Watch for unusually fast form completion, repeated details with small variations and clusters of signups from one network.
Small payment attempts. OWASP catalogs carding as a distinct automated threat, in which stolen card numbers are tested through low-value purchases. Repeated small payment attempts, especially with different card numbers in one session, are a pattern to investigate. Real-time transaction monitoring, one of several ways to mitigate banking risks, can flag these attempts before losses build up.
None of these signs proves fraud on its own. A customer may fail repeated logins because they forgot their password. Treat warning signs as reasons to look closer. Thales’ 2026 Bad Bot Report attributes 24% of the bot attacks observed in its full-year 2025 analysis to financial-services sites. That figure measures the distribution of observed attacks; it does not show the proportion of banks or customers affected.
Match each response to the risk
Choose a response according to the strength of the evidence and the sensitivity of the action. Checking a balance and sending money to a new payee warrant different levels of scrutiny.
Limit repeated attempts. Rate limiting caps how often a source can repeat a request, such as a login attempt. OWASP advises applying limits across multiple keys, including the account, session and endpoint, instead of relying only on an IP address. Set thresholds that fit your traffic. Rate limits should work alongside authentication and other checks because, as OWASP puts it, “A single control is brittle.”
Strengthen sensitive actions. Multifactor authentication (MFA) combines different types of proof of identity, such as a password and an authenticator-app code or security key. Methods differ in how well they resist phishing; a code entered on a fake page can still be stolen. NIST describes passkeys as less susceptible to phishing theft than passwords and as removing the need to memorize a login secret. They do not make an account immune to every attack. Apply stronger checks to sensitive actions such as adding payees, making large transfers and changing contact details.
| What you see | Illustrative response |
| Ordinary activity with no unusual signals | Let it continue without extra checks |
| Uncertain activity, such as a new device plus a failed login | Add a check before a sensitive action |
| Strong evidence of abuse, such as rapid attempts across multiple accounts | Restrict the activity and route it for review |
Use this table as a starting point. Test thresholds and responses against your customers’ activity before applying them broadly.
Recognize authorized automation. Customers may give budgeting tools or AI assistants permission to act inside their accounts. Controls that block all automation can interrupt services customers chose. Device and behavioral signals can inform a risk decision, but they cannot establish customer authorization on their own.
CHEQ‘s financial-services page distinguishes AI assistants acting inside authorized accounts from adversarial automation. The same page describes graduated responses, from letting a low-risk session proceed to stepping up checks, throttling or blocking. These are vendor-described capabilities, not independently verified results. When evaluating such controls, test their decisions against your own traffic and customer outcomes. Your institution remains responsible for access policies, identity verification and onboarding checks.
Measure protection from the customer’s side
A falling count of suspicious requests does not establish that customers are better protected. OWASP recommends volume metrics for each defense so teams can monitor its operation. Pair those figures with fraud outcomes and measures of customer access.
Check outcomes. Compare confirmed fraud incidents before and after a control goes live. If complaints rise without a clear improvement in fraud outcomes, review the control. Request counts alone cannot tell you whether it is preventing harm.
Check unnecessary barriers. Track how many legitimate customers were challenged or blocked, how many completed their task after a challenge and how many gave up. CGAP’s May 2026 working paper warns that aggressive antifraud measures can inadvertently exclude consumers. Review disputed decisions to understand which checks are causing avoidable problems.
Check data use. The same CGAP paper notes that fraud solutions’ dependence on consumer data raises privacy concerns, particularly for vulnerable groups. When evaluating any fraud-prevention provider, ask which signals it needs and how long the data is kept.
An institution-level scorecard could track these measures each month. These are suggested measures, not published benchmarks or verified product results. Review a sample of disputed decisions with your customer-support team to identify checks that need adjustment. This also helps you focus on balancing payment security and friction without relying on request counts alone.
Start with a sensitive journey, such as adding a new payee. Ask fraud and customer-service teams to review where legitimate customers abandon the process or need help completing a check.
FAQs
Are all automated requests harmful?
No. Some scripts replay stolen passwords or test stolen cards. Other automation acts with the customer’s permission, such as an assistant checking a balance. Automated behavior is a signal to assess alongside authorization and other evidence.
Is a strong password enough?
No. NIST notes that passwords are not phishing-resistant and advises adding multifactor authentication. An additional proof, such as an authenticator-app code or security key, helps protect an account when a password is stolen. Passkeys offer greater resistance to phishing and require no memorization.
Can extra checks inconvenience genuine customers?
Yes. CGAP warns that aggressive antifraud measures can exclude consumers. Apply stronger checks to sensitive actions and uncertain activity, and review which legitimate customers are being challenged or blocked.
What should happen after suspected account compromise?
Customers should contact their institution promptly so it can review recent activity and secure the account. IC3 advises resetting all credentials that may have been exposed during an account-takeover incident. That is a response to suspected exposure, not advice to change passwords on a routine schedule.
