A genuine code can approve a false action
The bank may send the message because somebody is attempting a real login, payee, payment or account change.
Protection, evidence and public rules
Does a bank ask for a password or two-factor authentication code?
A caller may use security language while asking for the very information needed to enter an account or approve a payment. A one-time code can be genuine even when the person asking for it is not.
Page P-019Guidance pageReviewed 29 August 2026
Key Guidance
Do not give a caller your full password, PIN or one-time security code. Do not approve a login or payment you did not start and understand. End the contact and check the claim with the bank through its official app or a trusted number.
Start with Key Guidance for the short answer. Then read the sections that match what happened and what you need to do.
Understand the issue
Why this matters to you
Banks use different authentication processes, but a security credential belongs inside the action it authorises. Moving it into an unsolicited conversation gives control to the caller.
The caller can reverse the meaning
A code that approves a transaction may be described as cancelling it, identifying the customer or securing the account.
Partial knowledge builds authority
Names, balances, recent transactions or card details can make later requests for sign-in details feel like a normal security check.
A prompt can be disguised as protection
An app approval may be presented as blocking fraud even though it authorises the caller’s action.
Consequences and movement
What may happen next
Read the bank’s own message and consider what you initiated. Do not let the caller interpret the prompt for you.
Account login
A password and second factor may allow the caller to enter online banking or another linked account.
New payee or payment
A code or app approval may create a recipient or authorise movement of money.
Security-detail change
The action may alter a phone number, device, password or recovery route and preserve access.
Follow-up transfer
Once the caller appears to know the account, they may instruct you to move money to a supposed safe account.
Practical response
What you should do
The independent bank route is the decisive check. A genuine security concern can survive the end of the call and be visible to the real bank.
- Do not disclose or approveDo not read out passwords, PINs or codes, send screenshots, type details into a supplied page or approve an action you did not start.
- End the contactDo not remain on the call while opening the bank app or searching for a number.
- Contact the bank independentlyUse the official app, the number on the card or a trusted statement. Explain the exact code, prompt and claim.
- Review account securityCheck recent devices, logins, payees, payments and changes. Remove anything unfamiliar with the bank’s assistance.
- Act immediately if you compliedTell the bank every credential, code and approval supplied, even if no loss is visible. Ask it to secure access and attempt to stop payments.
- Preserve and reportKeep the number, message, time, code description and transaction records, then report the impersonation and any fraud.
Look more closely
Security language can disguise a request for access or approval
Passwords, authentication codes and approval prompts can authorise entry or payment even when described as cancelling fraud. A bank should not need those secrets from you during an unexpected call.
A caller or message announces suspicious activity.
Urgency to prevent loss makes immediate cooperation feel necessary.
Real account details, a genuine code and security terminology imitate the bank.
The caller directs disclosure, app approvals or a new payment action.
Ending contact and entering the bank independently separates the real alert from the false explanation.
Selected history
Historical cases and lasting lessons
One-time-code interception
Scammers have sought genuine authentication codes while posing as security or support staff.
Lasting lesson: A code is not a conversation credential. It belongs only to the action described by the genuine service.
Bank impersonation calls
Spoofed numbers and accurate account information can be combined with urgent requests for sign-in details, approvals or transfers.
Lasting lesson: Caller ID and account knowledge do not replace an independently initiated bank connection.
Transferable understanding
Patterns over time
The contact uses real security activity
The scammer may trigger the code, so its arrival appears to confirm the caller’s story.
The instruction contradicts the message
The caller asks the customer to ignore or reinterpret warnings written by the bank.
Protection language conceals authority
Cancel, block and secure can be used to describe actions that actually log in, add or pay.
The process escalates
One disclosed code can lead to new sign-in details, remote access or a safe-account transfer.
Plain-language answers
Common questions
Can a bank ask security questions?
Banks use different checks. Do not provide a full password, PIN or one-time code to an unsolicited caller. Verify the process through the bank’s official route.
What if the caller says the code cancels a payment?
End the call and read the bank’s message yourself. Contact the bank independently before entering or sharing anything.
The caller knew my recent transactions. Are they genuine?
Not necessarily. Information may come from phishing, exposed data, screen access or earlier conversation. Use the independent bank route.
I shared a code but no money has gone. Am I safe?
Do not wait for visible loss. Contact the bank at once so it can review access, changes and pending actions.
Contact the bank before waiting for evidence of loss
Use the bank’s official app or a trusted number. Explain exactly what was disclosed or approved, then preserve the contact and use the appropriate fraud-reporting route.
Scamology Insights
Read the security action independently of the caller’s story
These learning resources can help reveal when a genuine authentication event becomes the claimed identity for unauthorised access or payment. Links are intentionally withheld in this production version.
Continue understanding
Explore related guidance
Evidence and currency