By: Money Navigator Research Team
Last Reviewed: 12/02/2026
FACT CHECKED
Quick Summary
Most Tide “security alerts” are signals that an action, device, permission change, or payment needs verification – not a conclusion that fraud has happened. The same alert style can also be imitated by scammers, so the channel (push vs email vs SMS) and the exact wording matter as much as the topic.
This guide explains the most common alert categories, what they typically relate to inside the account, and the practical impact on access and payments.
This article is educational and not financial advice.
What counts as a “security alert” in Tide
In practice, Tide security alerts tend to fall into two broad buckets:
Authentication and access alerts (who is trying to log in, from what device, and whether extra checks are needed).
Risk and control alerts (changes to payees, payment approvals, team permissions, or account checks that can affect what actions are allowed).
The key point is that an alert is usually a prompt for verification or a record of activity, rather than a detailed explanation. Some messages are deliberately brief because platforms often limit what they can share while checks are ongoing.
Where notifications arrive (push, email, SMS) and why it matters
Tide-related messages can appear as:
In-app prompts / push notifications: often tied to an action happening right now (log-in, approval, device verification).
Emails: commonly used for sign-in links, recovery flows, and certain security confirmations.
SMS: typically used for one-time passcodes or time-sensitive verification steps.
Because scammers can spoof sender names and mimic wording, the delivery channel and “what it’s asking for” are often more important than the brand name shown in the message. UK guidance on reporting suspicious messages is set out on GOV.UK’s phishing reporting page and the NCSC’s reporting guidance (for example, reporting a scam email).
Sign-in and device alerts: what they typically mean
These notifications usually relate to identity confidence (is this the right person) and device confidence (is this a recognised device).
1) “Log in from a new device” / “New device detected”
This typically appears when the account is being accessed from a device that Tide hasn’t previously associated with that login. The practical impact is often an extra verification step (for example, an email link plus a one-time code), rather than an automatic block.
Tide describes a device change/reinstall flow as “account recovery” and outlines the steps in its support content on logging in from a new device and account recovery.
Related internal context: Tide biometric login: what happens device vs app and Tide device & browser requirements: app vs web access differences.
2) “Biometric login changed” / “Biometrics disabled”
This type of alert usually reflects a local device setting change (face/fingerprint enrolment, lock screen settings, or app-level biometric toggles). It doesn’t necessarily mean the Tide account details changed; it can mean the phone’s biometrics changed.
Related internal context: Tide biometric login: what happens device vs app.
3) “Suspicious login attempt” / “We noticed unusual activity”
This wording is often used when something about the sign-in context looks different (location signals, device characteristics, repeated attempts, or rapid changes). The practical impact can range from no action (informational) to step-up checks (recovery flow, code prompt, or temporary lockout).
Verification alerts: codes, lockouts, and “account recovery”
1) “Your verification code is…” (SMS) or “Confirm it’s you” (email/app)
These are typically one-time verification steps linked to an ongoing action (login, recovery, sensitive change). The main operational impact is timing: codes expire quickly, and repeated retries can trigger throttling.
Related internal context: SMS verification lockouts: Tide triggers and recovery.
2) “Too many attempts” / “Try again later”
This usually indicates a temporary safety control. It can be triggered by repeated wrong codes, repeated PIN attempts, or repeated recovery tries in a short window. The platform is normally trying to reduce brute-force risk.
Related internal context: SMS verification lockouts: Tide triggers and recovery.
Team access and permissions alerts: roles, accountant access, and visibility
If a Tide account has multiple users, alerts often focus on who gained access and what level of control changed.
1) “A new team member was added” / “Role changed”
This typically means someone with admin-level ability has granted access or changed a role. The practical impact depends on what that role can do (e.g., add payees, send payments, approve payments).
Related internal context: Tide roles: admin, team member, cashier – what each can do.
2) “Accountant access granted” / “Third-party access updated”
These alerts usually reflect permissions being granted for viewing transactions, exporting data, or using connected tools. They don’t automatically imply payment rights were granted.
Related internal context: Giving accountant access: Tide permission boundaries and implications and Tide view-only access: what can be seen and what can’t be changed.
Payee and payment alerts: why these appear (even when nothing is “wrong”)
Payment-related alerts often exist because payees and approvals are common fraud points: if someone can add a payee or approve a payment, they can redirect funds.
1) “New payee added” / “Payee details changed”
This typically indicates that stored beneficiary details were created or edited. Many systems log this because it changes where money could be sent next.
Related internal context: Adding/removing payees: who can do it and what gets logged.
2) “Approval requested” / “Payment pending approval”
This usually reflects account configuration: some roles can initiate but not approve, or approvals may be required above certain thresholds. The practical impact is operational: the payment may not leave until approval happens.
Related internal context: Tide payment approvals and permissions for sending money.
3) “Name doesn’t match” / “Confirmation of Payee result”
For UK domestic payments, Confirmation of Payee (CoP) is an account name-checking service intended to reduce misdirected payments. A mismatch alert often means the payer-entered name isn’t close enough to the receiving account’s name format, not necessarily that the account is fraudulent.
Pay.UK describes CoP and how it operates on its Confirmation of Payee overview, and the Payment Systems Regulator explains its role in the UK market on its Confirmation of Payee page.
Related internal context: Confirmation of Payee in Tide: name matching and common mismatches.
Account review / restriction alerts: why details can be limited
Some alerts indicate that the account is undergoing checks (for example, information requests, compliance monitoring, or temporary restrictions). The practical impact varies widely: sometimes it’s a request for documents; sometimes it limits specific actions (like outbound payments) while checks run.
Where explanations are limited, it may reflect legal and operational constraints around what can be disclosed during certain checks. For context on the “tipping off” concept, UK legislation includes Proceeds of Crime Act 2002, section 333A.
Related internal context: Tide account under review: stages, timelines, typical outcomes and Why Tide can’t explain a restriction: tipping off and communication limits.
Summary Table
| Scenario | Outcome | Practical impact |
|---|---|---|
| New device / reinstall detected | Extra verification (“account recovery”) | Slower access until checks complete |
| Biometric setting changed | App may require PIN/re-enablement | Convenience change, not necessarily account change |
| Multiple failed verification attempts | Temporary lockout or throttling | Time-sensitive tasks may be delayed |
| New payee added / edited | Logged change; may prompt alert | Increases need for internal controls |
| Payment pending approval | Waiting for approver action | Payment timing depends on approval flow |
| CoP mismatch result | Warning about name alignment | Payment may be paused by the user flow |
| Account under review | Some actions limited during checks | Outbound payments/access may be constrained |
Scenario Table
| Scenario-level | Process-level (what’s being checked) | Outcome-level (what usually changes) |
|---|---|---|
| Access alert | Identity/device confidence | Step-up checks, recovery flow, or session reset |
| Verification alert | One-time factor validity | Code expiry, retry limits, temporary lockouts |
| Permissions alert | Authority and audit trail | Role scope changes; new access visibility |
| Payee alert | Beneficiary integrity | Payee stored/edited; later payments route differently |
| Payment alert | Approval and payee safety | “Pending” state until approval or confirmation |
| Review alert | Monitoring / information completeness | Temporary constraints; requests for information |
Tide Business Bank Account
Tide accounts are designed around app-based controls: access, payment actions, and team permissions are typically mediated through in-app roles and verification steps.
For a neutral walkthrough of the onboarding stages that can influence early security prompts (verification steps, identity checks, and account activation milestones), see Opening a Tide business account: steps and stages.
Frequently Asked Questions
Not necessarily. Many alerts are triggered by “difference signals” (new device, changed settings, unusual timing, or an action that changes where funds could go). These are common triggers across banks and app-based accounts because the system is trying to confirm identity or prevent misdirected payments.
That said, scam attempts often try to piggyback on genuine alert patterns. The operational takeaway is that an alert can be real while the message received (especially outside the app) can still be spoofed. That’s why the channel and the action requested matter.
Different channels serve different risk and delivery needs. SMS is often used for one-time passcodes because it’s immediate; email is often used for account recovery links; push/in-app prompts are used when the action is happening inside the app.
Channel choice also reflects reliability and security trade-offs. Email can carry longer instructions; SMS is short but widely delivered; push notifications depend on device settings and connectivity.
“Account recovery” typically means Tide is asking for extra checks before allowing full access again, commonly after reinstalling the app or using a new device. Tide outlines a recovery flow that can include an email link, an SMS passcode, and identity checks in its support guidance on account recovery.
Operationally, recovery can affect timing: access may be delayed until the checks complete. It can also affect workflows if approvals, payroll, or urgent outbound payments depend on that login completing.
This wording usually indicates rate limiting – a safety mechanism to reduce guessing or repeated attempts. It’s commonly triggered by repeated incorrect codes, repeated PIN entry failures, or repeated recovery attempts within a short time window.
The practical impact is that some actions become time-bound (for example, approval windows or payment cut-offs). For a Tide-specific explanation of triggers and recovery patterns, see SMS verification lockouts: Tide triggers and recovery.
A payee add/edit alert usually means the account’s beneficiary list has changed. This is significant because future payments can be sent to that stored destination more easily, and many systems treat it as a higher-risk action than sending a one-off payment.
In team setups, this also connects to role scope and audit trails: whether the person who added the payee also has rights to approve or send payments. Tide-specific role boundaries are covered in adding/removing payees: who can do it and what gets logged.
A CoP mismatch typically means the name entered doesn’t sufficiently match the receiving account’s name format on record. That can happen for completely legitimate reasons (trading names, abbreviations, personal vs business indicators, spacing/punctuation differences, or legal entity suffixes).
CoP is designed to reduce misdirected payments and provide additional assurance. Pay.UK explains CoP at a scheme level on its Confirmation of Payee overview, and the Payment Systems Regulator provides regulatory context on its Confirmation of Payee page. For Tide-specific mismatch patterns, see CoP in Tide: common mismatches.
“Pending” commonly reflects workflow state: approvals required, insufficient permissions, or a queued payment awaiting the next step. “Under review” wording more often implies additional checks are being performed before the action can proceed.
The operational differences can be significant. “Pending approval” depends on internal authorisation flows (who can approve, and when), while “under review” depends on checks outside the immediate payment flow. Tide’s approval mechanics are covered in payment approvals and permissions, while broader review states are covered in account under review: stages and outcomes.
Short explanations can reflect both practical and legal constraints. Some checks rely on third-party information, automated monitoring, or ongoing investigations where revealing specifics can undermine the process.
In the UK, “tipping off” is a concept referenced in legislation, including Proceeds of Crime Act 2002, section 333A. In plain terms, platforms may limit what they say while checks are ongoing. Tide-specific communication limits are discussed in why Tide can’t explain a restriction.
These alerts typically relate to who can see information (transactions, statements) and who can take actions (adding payees, sending money, approving payments). In many setups, “view-only” access is deliberately separated from “payment” permissions to reduce operational risk.
The practical impact is governance: auditability, separation of duties, and reducing the chance that a single compromised login can both create and execute changes. For Tide-specific boundaries, see giving accountant access, roles and capabilities, and view-only access limits.
Some platforms allow notification preferences to be changed by channel or category, but the availability and granularity vary by alert type. Security-critical alerts are often kept on by default because they form part of the audit trail and rapid detection process.
The trade-off is operational rather than financial: fewer notifications can reduce noise, but it can also reduce the speed at which unusual access patterns or permission changes are noticed. Where a platform offers alert preference controls, they are usually framed around convenience versus visibility rather than changing the underlying security controls.
Security alerts are best understood as state signals – the platform announcing that something important changed (identity context, device context, authority context, payment context) or that it needs additional certainty before proceeding. The most useful mental model is that alerts are part of a control system: they either:
- Record a meaningful event
- Request an extra factor to raise confidence.
When alerts become vague (“we can’t share more”), that often reflects a second constraint: communication itself can change behaviour.
Even without assuming wrongdoing, detailed explanations can inadvertently reveal the shape of monitoring, enabling workarounds.
That’s why many platforms standardise alert language into short categories and rely on in-app status states rather than narrative detail.
Related Content
