Peer-to-Peer Payment

A peer-to-peer payment is a transfer of money between two individuals made through a mobile or web application, where the recipient is identified by a phone number, email address, or username rather than by a bank routing and account number. The category covers bank-consortium networks built into banking apps and independent apps that carry their own balances, and it is descriptive rather than legal: no regulator defines the phrase.

The rules nonetheless reach these services squarely, and the mechanism is worth knowing because it is counter-intuitive. Regulation E defines a financial institution at 12 CFR 1005.2(i) as "a bank, savings association, credit union, or any other person that directly or indirectly holds an account belonging to a consumer, or that issues an access device and agrees with a consumer to provide electronic fund transfer services." A technology company that is not a bank and holds no charter falls inside that definition the moment it holds a consumer asset account. The definition of account at 1005.2(b) reaches the same result from the other side, since it includes a prepaid account whose primary function is to conduct transactions with unaffiliated merchants or "to conduct person-to-person transfers."

So the answer to "is my payment app regulated" is generally yes, and the answer to "does that mean my money is safe" is a different question with a different answer, which is what the rest of this page is about.

The split that decides everything is where the money rests. In a rail-based service, the app is an addressing and routing layer over the banking system: your bank is debited, the recipient's bank is credited, and nothing of yours is ever held by the provider. In a stored-balance service, received money accumulates in a balance held by the provider until you move it out, and that balance is an obligation of a technology company rather than a deposit at a bank. Many services now do both, which is why the question is about a particular payment rather than about a brand.

A stored balance is not a bank deposit, and the difference is not cosmetic. Providers typically place pooled customer funds at one or more partner banks, and federal deposit insurance can reach an individual customer's share of that pool through rules that treat the provider as holding the money on the customer's behalf. That works when the recordkeeping is accurate enough to establish who owns which share. It is not a promise the user can verify, the determination is made only when a bank actually fails, and it protects against the bank failing rather than against the provider failing. The fintech page covers the pass-through mechanics; the shorter version worth carrying is that a balance left in an app is money in a place whose protection depends on somebody else's bookkeeping.

Who pressed the button decides who bears a loss. Regulation E's protections for unauthorized transfers are strong, and they apply to these apps in the ordinary way: a transfer someone else initiates from your account, including after tricking you into revealing a login or a texted code, is unauthorized, and your liability is capped by how quickly you report. A payment you initiated yourself is not unauthorized under the regulation, whatever you were told to induce it, and the error-resolution rules do not contain a limb for goods that never arrive. That is the whole reason the standing advice about these apps is to treat them like cash between people you know.

Buyer protection, where it exists, is contractual. Several providers offer protection on payments flagged as being for goods and services, usually in exchange for a percentage fee charged to one side of the transaction. That protection is a term of the provider's user agreement. It is not a statutory right, its scope is defined by the agreement rather than by a regulation, it can be amended, and it does not attach at all to a payment sent as a personal transfer. Reclassifying a payment after the fact is generally not possible, which makes the choice at the moment of sending the operative one.

Two smaller mechanics that cause real problems. First, payments are addressed to tokens, and a token can be mistyped or can belong to someone who is not who the display name suggests, because the name shown to a sender is supplied by the recipient's enrollment rather than verified against a legal identity. Second, receiving business income through one of these apps is a reporting event, and the thresholds and forms involved have changed more than once, so a person selling regularly through a payment app has a tax question as well as a payments question.

You link a bank account or a debit card, and the app registers a token, usually a phone number or email address. To pay someone you enter their token and an amount. On a rail-based service the instruction is routed to the recipient's bank and the money lands in their account; on a stored-balance service the amount is credited to their balance in the app, and moving it to a bank account is a further step that may be instant for a fee or free after a delay.

A hypothetical example of what the goods-and-services election actually buys, using an assumed fee. Providers set and disclose their own.

Nour buys a used bicycle for $300 from someone she found in a local listing. She has two ways to send the money through the same app.

Sent as a personal transfer, the payment costs nothing. If the bicycle never arrives, she has no claim under the provider's protection program and no federal error-resolution route either, because she initiated the payment herself and the electronic-transfer rules contain no provision for goods that were not delivered.

Sent as a goods and services payment at an assumed 2.99% seller fee, the fee is $8.97 ($300 times 0.0299) and comes out of the seller's proceeds, so the seller receives $291.03 ($300 minus $8.97). In exchange Nour is inside the provider's purchase protection program, on whatever terms that program sets.

The nine dollars is not really the price of the protection to Nour, since the seller pays it and may simply raise the price. What she is actually choosing is between a contractual claim against the provider and no claim at all, and the choice is only available before she sends. It is also worth noticing what neither option is: a credit card purchase, where non-delivery is a statutory billing error rather than a term of somebody's user agreement.

Pros

• Fast, usually free between individuals, and addressed by information people already share rather than by account numbers.
• Covered by the federal electronic-transfer rules whether or not the provider is a bank, because the definition that brings them in is functional.
• A transfer initiated by someone else from your account carries capped liability and a defined investigation procedure.
• Some providers offer purchase protection on goods-and-services payments, which is more than a cash payment carries.

Cons

• A payment you sent yourself is outside the unauthorized-transfer protections, and there is no federal non-delivery remedy on this rail.
• Purchase protection is contractual rather than statutory, so its terms are set by the provider and can change.
• A balance left with a nonbank provider is not a bank deposit, and any insurance reaching it does so indirectly and depends on records the user cannot inspect.
• Payments are addressed to tokens, and a display name is not a verified legal identity.
• Instant transfers out of a stored balance usually cost a percentage fee, so the free version of the service is the slow one.