Banks and telecom providers need shared intelligence, aligned escalation rules and clear ownership for contacting customers when scam patterns emerge across channels. Neither side sees the full attack path on its own. The strongest model is coordinated detection that joins messaging, call, email and payment signals into one operating picture.
Why shared scam prevention has to be a joint operating model
scam prevention breaks down when banks and telecom providers treat the problem as two separate cases. The customer experiences one fraud journey, but the controls sit in different places: messaging, voice, email and payment rails. Shared responsibility means each party acts on the signals it can see, then passes those signals into a common escalation path so the other side can intervene quickly and consistently.
The practical test is whether the organisations can turn partial telemetry into a single decision. That includes matching suspicious message content, call patterns, account activity and payment indicators, then deciding who warns the customer, who blocks or delays the transaction, and who records the case for follow-up. Without that handoff, scams keep moving across channels faster than any one provider can see them.
For payment-led scams, the strongest pattern is the one set out in the Authorised Push Payment (APP) Fraud Guide: align detection, warning and reimbursement handling so the bank can act on a credible fraud signal even when the scam started elsewhere.
What each side is actually responsible for
Banks are usually closest to the money movement, so they own payment friction, confirmation checks, account restrictions, recall attempts and customer remediation when funds are at risk. Telecom providers are usually closest to the inbound contact channel, so they own abuse detection for calls and messages, number reputation, suspicious traffic analysis and interruption of harmful communications.
Neither side should wait for perfect proof from the other. In practice, the bank may see a first payment attempt that looks coerced or unusual, while the telecom provider may see a call or message campaign that is clearly part of a scam. The responsibility is to surface those observations fast enough that the other party can act before the scam is completed.
That is why the operational split is not “bank fraud versus telecom fraud”, but “channel signal versus financial signal”. The organisations need defined ownership for evidence, customer contact and case closure, otherwise each side will assume the other is already handling it.
Shared models work best when they are explicit about who initiates outreach, who confirms escalation, and what level of confidence is enough to trigger action. If those thresholds differ, one provider will hesitate while the scam progresses.
Where scam prevention fails in practice
The most common failure is fragmentation. A telecom provider blocks a number or message stream, but the payment warning never reaches the bank in time. Or a bank sees a suspicious transfer, but the caller or message thread that induced the payment is invisible to it. Scammers rely on that gap, because they only need one weak handoff to complete the fraud.
A second failure is unclear customer-contact authority. If both firms try to warn the same customer without coordination, the message can look contradictory or confusing. If neither feels authorised to contact the customer first, the scammer keeps control of the interaction.
A third failure is poor evidence joining. If call records, message logs and payment data are not linked through shared identifiers or case references, the pattern remains invisible. The result is slower detection, weaker prioritisation and less effective recovery action.
These are process failures, not just technology failures. Even strong detection tools do not help if escalation rules, ownership and timing are undefined.
Risk and Threat Considerations
Scam networks depend on cross-channel drift, they move the victim from message or call to payment before any single provider can interrupt the sequence. That means the risk is not limited to a bad transaction or a bad message, it is the combined failure to see the scam as one campaign.
Failure mechanism: The attacker uses one provider to create trust and the other to complete the loss, while each organisation sees only a partial incident and delays intervention until the scam has already progressed.
Impact: Customers receive inconsistent warnings, fraud is harder to stop early, recovery becomes less likely, and the organisations absorb greater financial loss, complaint volume and reputational damage.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OC-03 — External Dependencies and Relationships | Shared scam prevention depends on coordinated duties between banks and telecoms. |
| PR.AA-05 — Authenticator Management | Customer-contact and channel controls rely on strong identity and access handling. | |
| RS.CO-02 — Incidents are Reported Consistent with Criteria | Scam response depends on fast, consistent escalation between organisations. | |
| Recommendation — Define joint escalation ownership and evidence-sharing paths across providers. Use controlled authentication and verification before sensitive account actions. Establish criteria for when one party must notify the other immediately. | ||
| NIST SP 800-53 Rev 5 | AU-6 — Audit Record Review, Analysis, and Reporting | Joined scam detection requires correlating logs across channels and systems. |
| IR-4 — Incident Handling | The subject is coordinated response to active scam events across firms. | |
| Recommendation — Correlate call, message and payment telemetry to support fraud investigation. Set cross-organisation incident handling steps for scam escalation and containment. | ||
| CIS Controls v8 | CIS-17 — Incident Response Management | Banks and telecoms need a shared response process for scam cases. |
| Recommendation — Create a joint response playbook for scam warnings, escalation and customer contact. | ||
Practitioner Guidance
What to prioritise: Define a single joint escalation path before tuning detection thresholds. If the bank and telecom provider cannot agree on who contacts the customer, what evidence is sufficient, and how quickly a case must move, the rest of the control stack will underperform.
What to verify: Test that message, call and payment signals can be correlated into one case record, and that either party can trigger a timely customer warning without waiting for manual cross-approval. The control should work under pressure, not only in a tabletop exercise.
Decision rule: If one party has enough signal to suspect an active scam, treat speed as more important than perfect attribution. The objective is to interrupt the scam path early, then reconcile ownership and reimbursement details after the customer is protected.
Practitioner takeaway: Shared responsibility works only when both organisations agree that scam prevention is a joint interruption problem, not a sequential handoff problem.
Related resources from NHI Mgmt Group
- How should fraud, security, and product teams share responsibility for AI scam prevention?
- What happens when scam intelligence is not shared across banks, exchanges, law enforcement, and platform providers?
- What happens when utilities and telecom providers do not share payment data with credit bureaus?
- Who should share responsibility for healthcare cybersecurity when vendors and providers both depend on the same systems?