What Is Person-to-Person Payments? Definition & Examples

Person-to-person payments are transfers of money between individuals using a mobile app or digital payment service. They typically move funds through linked cards, bank accounts, or payment networks, and they are designed for fast, low-friction consumer transactions rather than business settlement or enterprise payment workflows.

Expanded Definition

Person-to-person payments, often shortened to P2P payments, describe consumer transfers between two people through a digital app or payment service. The term covers the user experience layer, the transfer rail behind it, and the account-linking methods that fund the transfer. It excludes business payments, payroll, merchant checkout, and treasury workflows, even when the same underlying network is used.

In security and identity discussions, the important boundary is that P2P is usually optimised for speed and convenience, not for transaction complexity. That design choice changes how fraud screening, account recovery, and recipient verification are implemented. A common misunderstanding is to treat all digital payments as one control problem; in practice, a P2P transfer may have lighter authentication, different dispute handling, and weaker contextual signals than a card purchase or bank-to-bank settlement.

Where the service supports aliases, phone numbers, or email-based discovery, the trust model also shifts from account numbers to identity resolution. That makes naming, enrolment, and lookup quality part of the security conversation, not just the product experience. For a standards-based view of payment security boundaries, the PCI Security Standards Council remains useful background even though P2P flows may only partially intersect card data handling: PCI Security Standards Council.

Examples and Use Cases

P2P payments appear in a narrow set of everyday workflows, but each one carries a different trust assumption:

A roommate reimburses rent-related costs through a mobile wallet, where speed matters more than invoicing or reconciliation.
A family member sends money to a relative using a phone number or email address, relying on directory-style recipient lookup.
A small peer-based resale transaction uses a consumer payment app instead of cash, shifting risk from physical exchange to account verification.
A social payment in a group setting is completed through a linked bank account or card, where funding source and app credentials both matter.
An app-specific transfer is used for instant settlement between known contacts, often with limited ability to reverse the payment once sent.

The practical trade-off is convenience versus certainty. Faster initiation reduces friction, but it can also reduce the chance that the sender re-checks the recipient, notices an impersonation attempt, or pauses before authorising a transfer. In real environments, the user interface often becomes the first control surface for preventing mistaken or manipulated payments.

Security Implications

P2P payments create security exposure when the system assumes the sender can reliably identify the recipient and understand the consequences of finality. If a fraudster redirects a user to the wrong account, the payment may look legitimate to the platform even though the human intent was compromised. That makes social engineering, account takeover, and recipient-misdirection especially damaging in this channel.

Operationally, the most visible failure mode is a legitimate transfer to an unintended recipient, followed by rapid fund movement before the error is detected. In parallel, compromised consumer accounts can be used to send small, repeated payments that evade casual review. Because P2P services are built for low-friction use, weak enrolment, reused credentials, or poor device trust can become the practical path into the payment account.

For organisations that support consumer payments, the practitioner observation is straightforward: dispute handling and fraud detection must account for user intent, not only transaction syntax. A syntactically valid payment can still be a security incident if the recipient identity was spoofed, the sender was manipulated, or the account was taken over.

Domain and Governance Relevance

P2P payments sit at the intersection of consumer payments, fraud controls, and identity assurance. The governance question is not only whether the transfer completed, but whether the platform can prove who initiated it, who received it, and whether the user understood the destination. That is why enrolment, step-up authentication, and beneficiary verification are central design choices rather than afterthoughts.

In identity terms, P2P systems often depend on phone numbers, email addresses, device binding, and account reputation as practical trust anchors. Those signals are weaker than formal enterprise identity governance, so service owners need clearer ownership for onboarding, recovery, and error resolution. Where a payment app also exposes API-driven capabilities, the same lifecycle concerns can apply to machine-access pathways that support transfers, notifications, or reconciliation.

For NHIMG, the key relevance is that low-friction consumer transfer systems still depend on identity decisions, even when they are not framed as IAM products. The control question is how much trust the platform assigns to the claimed recipient and how quickly that trust can be abused.

Risk and Threat Considerations

P2P payments are exposed to authorised-payment fraud, social engineering, and account takeover because the system often treats a user-approved transfer as sufficient proof of intent. The risk is amplified when recipient discovery is based on aliases or contact data rather than strong beneficiary validation.

Failure mechanism: An attacker or scammer convinces the sender to authorise a transfer to the wrong recipient, or gains control of the sender’s account through credential theft, session abuse, or recovery weakness. Once the payment is submitted, the low-friction design can make interception or reversal difficult.

Impact: Funds may be lost quickly, user trust declines, fraud operations scale across many small transfers, and the provider may face higher support load, chargeback-like disputes, and weakened confidence in recipient verification controls.

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 and CIS Controls v8 set the technical controls, while PCI DSS v4.0 define the regulatory obligations.

Framework	Control / Reference	Relevance
NIST CSF 2.0	PR.AC — Identity Management, Authentication, and Access Control	P2P systems rely on strong sender authentication and account recovery.
	DE.CM — Security Continuous Monitoring	Fraud and takeover signals in P2P systems depend on continuous detection.
Recommendation — Enforce stronger authentication and recovery controls for payment accounts and beneficiary changes. Monitor for anomalous payment patterns, new device enrolment, and recipient-change activity.
CIS Controls v8	5 — Account Management	P2P platforms must manage consumer accounts, aliases, and recovery paths carefully.
	8 — Audit Log Management	P2P disputes and fraud investigations depend on reliable transaction and identity logs.
Recommendation — Track and remove stale payment access paths and tighten account lifecycle controls. Keep immutable logs for login, enrolment, recipient lookup, and transfer events.
PCI DSS v4.0	8 — Identify Users and Authenticate Access to System Components	Where card-funded P2P flows exist, authentication and access control remain central.
Recommendation — Apply stronger authentication to payment access paths that can move funds or change beneficiary details.

Person-to-Person Payments