Security Insights

Most customer-facing phishing advice bottoms out at "do not click links." Branch staff repeat it; customers ignore it. The advice fails because it asks the customer to override a behavior that legitimate marketing also encourages. The honest list is shorter and asks for specific behaviors rather than blanket suspicion.

Red flags

Urgency that names a clock. "Account suspended in 24 hours" is almost always fabricated. Real institution warnings give specific failure modes and specific remedies. Mismatched reply-to and from domains — the visible name can say anything; the underlying headers cannot. Embedded links that require login; marketing emails do not require login, service emails do not require login, any email that demands credentials on click is suspect regardless of sender. Attachments the customer did not request; statements are pushed via portal, not email; wires are confirmed by call-back, not PDF.

The script

The script branch staff should learn is not "is this phishing?" but "what does the customer want, and what is the legitimate channel for that?" Phishing exploits the customer's certainty that the email is real; the script exploits the customer's uncertainty about the channel. Train to the channel, not to the threat.

Most community institutions publish partial email authentication records. SPF includes too little or too much. DKIM signs with one selector and rotates never. DMARC is set to p=none and stays there. The gap between "configured" and "audited" is where attackers live.

SPF

List every sender authorized to mail from your domain. Include marketing platforms, statement vendors, payroll providers, and any service that sends as you. SPF fails not because the syntax is wrong but because the list is incomplete. Use the soft fail (~all) during audit, then move to hard fail (-all) once the list holds for thirty days without complaint.

DKIM

DKIM signs every outbound message with a private key held by the sending server. Most institutions sign with one selector that never rotates. Auditable DKIM uses at least two selectors, rotates them annually, and logs rotation in change management.

DMARC

DMARC tells receivers what to do with mail that fails SPF or DKIM. The audit posture is p=none with rua= reporting going to a mailbox someone actually reads. After thirty days of clean reports, move to p=quarantine. After another thirty clean days, p=reject. Skipping the p=none step is how legitimate traffic ends up in spam.

Keep evidence: the SPF record, the DKIM public keys, the DMARC reports, the rotation log. Auditors do not want the configuration; they want the evidence that the configuration has been operated.

The first sixty minutes after a fraudulent wire is confirmed determine whether funds are recoverable. Once the money leaves correspondent banking rails, recovery rates drop below ten percent. The playbook below assumes a business-hour detection; after-hours detection is harder and slower.

Minutes 0–10 — Confirm

Pull the original instruction, the call-back record, and the approval chain. Identify whether the request came through a compromised vendor, a compromised employee, or a spoofed email. Do not call the customer yet; the customer may be the source.

Minutes 10–20 — Recall

Call the receiving institution's fraud line, not the general customer service number. Ask for a recall on the wire and a freeze on the receiving account. Have the wire reference number, the amount, and the recipient name ready. The receiving institution will not move without all three.

Minutes 20–35 — Notify

File a complaint with the FBI's IC3 at ic3.gov and contact your local FBI field office. For wires over fifty thousand dollars, the Financial Crimes Enforcement Network offers a rapid-response protocol that can flag the funds before they leave the country.

Minutes 35–60 — Document

Notify your own institution's fraud team, your regulator, and your cyber insurance carrier. The carrier may have specific notification requirements that affect coverage. Document everything: time of detection, time of each call, name of each contact, reference numbers issued. The documentation is what auditors, regulators, and counsel will use to reconstruct decisions made under pressure.

The playbook fails when it has never been rehearsed. Tabletop the scenario quarterly. The first time anyone on your team calls a recall line should not be during an actual event.

SMS-based one-time passwords have known weaknesses for fifteen years. They fail in three specific ways, and each has a known mitigation that costs less than the loss it prevents.

Interception

Attackers convince mobile carriers to port the victim's phone number to a controlled device (SIM swap) or convince the victim to forward the code (social engineering). The mitigation is number-port protection on every customer mobile account, with carrier-side PIN requirements. Most banks do not enforce this for customers; some do not even enforce it for staff.

Replay

A code intercepted at one institution is functionally identical to a code intercepted at another, if the customer reuses the underlying credential. The mitigation is institution-bound codes — the OTP is bound to a device attestation that does not leave the customer's hand.

Friction fatigue

Customers asked to enter a code for every login learn to enter codes without reading them. Adversary-in-the-middle tooling exploits this: the victim enters the code on the proxy site, the proxy forwards it to the real site, and the victim sees nothing wrong. The mitigation is number-matching push notifications, where the customer must match a number displayed on the bank's side to a number displayed on their device.

What replaces it

What replaces SMS OTP is not a single technology but a posture: bind the second factor to a device the customer physically holds, require an action that cannot be replayed, and rate-limit attempts aggressively. FIDO2 keys, passkeys, and number-matching authenticator apps all fit this posture. The cost of deployment is real; the cost of not deploying is higher.

Authentication documentation fails audits for the same reason it fails operations: it is written for the wrong reader. The auditor wants evidence; the operator wants runbooks; both end up reading the same sprawling document that serves neither.

The structure that works is three documents, each less than ten pages.

Control statement

What the institution requires for authentication of customers, staff, and counterparties. One page per audience. Names the control, names the owner, names the review cycle.

Operating evidence

Screenshots, logs, and configuration exports that demonstrate the control is in operation. Dated, labeled, and stored in a single location. The auditor does not want the configuration; the auditor wants proof the configuration is live.

Decision log

Every exception, every workaround, every temporary deviation, with a date, a reason, an approver, and a review date. Exceptions that have no review date are how controls erode.

What goes wrong: the control statement tries to be the operating evidence; the operating evidence tries to be the runbook; the decision log does not exist. The fix is to refuse to combine them. Each document answers one question for one reader, and the cross-references between them are stable. Auditors who have read this structure once ask for it forever. Operators who use it stop dreading the audit cycle.

Marketing platforms, statement vendors, and CRM tooling send mail as the institution. The arrangement is convenient for the institution and convenient for attackers. The same authentication that authorizes the vendor authorizes anyone who compromises the vendor.

The pattern

Vendor sends mail from statements@yourbank.com on your behalf. SPF includes the vendor's outbound IPs. DKIM signs with a vendor-managed selector. The vendor is compromised, and the attacker now sends mail that passes every authentication check your customers rely on.

Mitigations

Scope the authorization. Vendor SPF includes should be as narrow as possible. Use include: rather than ip4: only when the vendor publishes a stable, narrow SPF; avoid include: against vendors who use broad cloud pools; require dedicated IPs.

Sub-domain the vendor. Statements come from statements@statements.yourbank.com, not statements@yourbank.com. Customer education can reinforce the sub-domain pattern; it cannot reinforce vague intuition about the apex domain.

Monitor outbound volume. A vendor that suddenly triples volume is either running a campaign or being used for one. Real-time volume alerts, with a human who can pull the include on short notice, are how the second case gets caught.

Rotate DKIM selectors. Vendor-managed selectors should rotate at least annually. Selectors that have not rotated in two years are a sign that no one is minding them.

Revocation

Plan for revocation. When the vendor is compromised, the include must come out within minutes, not days. Rehearse the revocation; the first time should not be during an event. Third-party senders are not going away; the work is in scoping them narrowly enough that compromise is recoverable.