Fraud that depends on sustained interpersonal trust rather than a single technical compromise. Attackers invest time in conversation, reassurance, and credibility building so that the victim willingly authorises transfers or shares sensitive information. This makes the control problem behavioural as well as technical.
Expanded Definition
Relationship-based fraud is a social engineering pattern in which the attacker does not rely on a one-time exploit, but on trust accumulated over repeated contact. It often resembles normal business communication at first, which is why it can progress across email, messaging apps, voice calls, and collaboration tools without triggering obvious suspicion. The defining feature is not the channel, but the deliberate cultivation of familiarity, urgency, and credibility until the target takes an action that appears self-authorised.
Definitions vary across vendors when this behaviour is grouped under impersonation, business email compromise, or online romance scams, but the security problem is the same: a human decision is manipulated into becoming the attack path. In governance terms, this sits closest to identity assurance, transaction approval, and anti-fraud controls, especially where step-up verification is weak or bypassed under pressure. Controls described in NIST SP 800-53 Rev 5 Security and Privacy Controls are relevant because they address access control, identification, monitoring, and incident response around trusted actions.
The most common misapplication is treating relationship-based fraud as a simple phishing event, which occurs when organisations focus only on message authenticity and miss the longer trust-building phase.
Examples and Use Cases
Implementing defences against relationship-based fraud rigorously often introduces friction in legitimate communications, requiring organisations to weigh faster approvals against stronger verification.
- A finance manager is groomed over several weeks by a fake supplier contact, then convinced to update payment details and authorise a transfer.
- A scammer maintains a convincing chat-based relationship with an employee, gradually requesting internal process details that enable later impersonation.
- A senior executive receives repeated messages from someone posing as a trusted adviser, eventually approving an urgent payment outside normal channels.
- A customer support agent is manipulated into resetting access or disclosing account information after repeated, credible-seeming conversation.
- An attacker uses cloned identities and routine check-ins to build trust before requesting sensitive files, credentials, or out-of-band approvals.
These scenarios commonly overlap with business email compromise, pretexting, and account takeover, but the relationship-building phase is what distinguishes them. For teams designing controls, NIST guidance on authentication and account recovery is useful when paired with user training and transaction verification. The broader pattern is also discussed in security awareness materials from CISA guidance on avoiding social engineering and phishing attacks, which helps explain why trust signals can be weaponised across channels.
Why It Matters for Security Teams
Relationship-based fraud matters because it bypasses many controls that are strong against malware but weak against persuasion. If teams only harden endpoints, filter messages, or block known malicious infrastructure, they may still miss the attacker who has already won a human decision. That creates exposure in payments, account changes, privileged approvals, and sensitive data disclosure, especially where exceptions are common and verification is inconsistent.
For identity and fraud teams, the issue is not just whether the user is real, but whether the request is legitimate in context. This is where identity assurance, behavioural anomaly detection, and approval workflow design intersect. Guidance in NIST resources on cybersecurity training and education can help reinforce recognition of coercion and pretexting, but training alone is not sufficient. Organisations need verification steps that are hard to socially engineer, especially for sensitive actions involving funds, credentials, or privileged access.
Organisations typically encounter the true impact only after a trusted contact has already induced an irreversible transfer or disclosure, at which point relationship-based fraud becomes operationally unavoidable to investigate and contain.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5, NIST SP 800-63 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA, PR.AC, DE.CM | Identity assurance, access control, and monitoring help detect socially engineered trusted actions. |
| NIST SP 800-53 Rev 5 | AC-2, IA-2, AU-6, IR-4 | Access, authentication, logging, and incident response controls support fraud detection and containment. |
| NIST SP 800-63 | AAL2, AAL3 | Assurance levels inform how strongly a user or approver should be verified before trust-based actions. |
| NIST AI RMF | The govern and manage functions support risk assessment for persuasive and deceptive human interaction. | |
| OWASP Non-Human Identity Top 10 | NHI governance matters when fraud uses stolen or manipulated machine identities to sustain trust. |
Harden approvals, monitor anomalous requests, and verify identity before sensitive actions are executed.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on July 12, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
