First-party fraud

The real account holder carries out the operation and later disowns it. Why it is a different problem from impersonation, where it actually gets resolved, and what a strong identity verification contributes when the dispute arrives.

What first-party fraud is

First-party fraud happens when the one who defrauds is the legitimate holder of the account, the product or the payment method. There is no impersonation, no stolen credentials and no third party involved: the person carrying out the operation is exactly who the system believes they are, and afterward denies having done it or deliberately fails to honor what they took on.

The most frequent form is disowning a purchase that was in fact made. Also included are defaulting on the first payment of a loan requested with no intention of paying it, falsely declaring that a product never arrived, systematically abusing a returns policy, and inflating a real claim.

The name comes from the position it occupies in the transaction: the first party is the customer themselves, as opposed to a third party attacking from outside.

It is not an identity verification problem, and that is worth saying

It is the most important statement on this page. Identity verification worked. The holder is real, the document is valid, the face matches, the authentication succeeded. No identity control could have prevented this operation because there is nothing anomalous to detect: the right person did what they wanted to do.

That separates it from almost every other fraud type in the catalog. A deepfake, a synthetic identity or a video injection attack attack the question of who is on the other side. First-party fraud doesn't attack that question: it answers it correctly and defrauds anyway.

What a strong verification does change is the organization's position when the case is disputed. That distinction, between preventing and proving, is what organizes the rest of the page.

How the case runs, step by step

The sequence has no technical sophistication. Its effectiveness lies in how the burden of proof is distributed.

  1. The real operation. The holder buys, transfers, requests the loan or contracts the service, with their credentials, their usual device and their usual behavior. There is no risk signal to raise, because nothing is irregular.
  2. Delivery. They receive the goods, consume the service, dispose of the money or use the credit line.
  3. The disavowal. They declare to the issuer, the merchant or the institution that the operation wasn't authorized, that the product never arrived, or that the service wasn't provided.
  4. The dispute. The chargeback or formal claim is opened. In most payment schemes and in much of the region's consumer protection regulation, the burden of proof falls on the merchant or the institution, not on the one who claims.
  5. The evidence review. The organization looks for what it kept from the moment of the operation. If it has a session log and an IP address, it has little. If it has an element that ties the operation to the person, it has a case.

Step 5 is the only one where the organization has room to decide, and it gets defined earlier: in what evidence it chose to keep when it designed the flow, months before the dispute appeared.

The variants that get confused with each other

Grouping them under the same label leads to measuring the problem badly, because each one is contained in a different part of the organization.

  • Disowning a purchase — the classic variant, also known as friendly fraud. It is disputed in the payment method's chargeback circuit.
  • Intentional default on the first payment — a loan requested with no intention of paying it, which shows up in the portfolio as early delinquency and is contained with origination models.
  • Abuse of returns or refund policy — within the merchant's rules, repeated until it becomes that account's usage pattern. It is a commercial policy decision before it is a fraud control.
  • Inflated claim — a real incident whose scope is exaggerated. It is the hardest to classify and the one that requires the most human judgment.
  • Bust-out — the extreme case: months of good behavior to exhaust all available credit at once and disappear. It shares the logic of the holder who defrauds, with the difference that the identity behind it is usually fabricated.

Part of these cases isn't fraud. There are good-faith disavowals from a relative's purchase, forgotten recurring charges and unrecognizable merchant descriptors on the statement. Treating the entire volume as deliberate fraud creates friction for legitimate customers, and that cost is rarely measured.

Who it affects and what it costs

  • E-commerce — it is the point of greatest exposure. The merchant loses the product, the amount and the fee, and adds the administrative cost of disputing. In repeated cases, the impact on its chargeback ratio also affects its relationship with the acquirer.
  • Financial services and card issuers — absorb the dispute and the process, and arbitrate between their customer and the merchant.
  • Consumer credit and financing — intentional default mixes with genuine delinquency, and separating them defines whether the problem goes to credit risk or to fraud.
  • Service and subscription platforms — the consumption already happened and can't be reversed, which leaves the refund as the only variable.

The least visible cost is organizational: first-party fraud tends to fall into no man's land between the fraud team, the credit risk team and customer service. Without an owner, it isn't measured, and without measurement it never appears in any product decision.

What controls contain it

None of them is an identity control, and several aren't software controls. Naming them all is what makes the list useful.

  • Holder behavior analytics — frequency of claims, dispute history, relationship between the disavowal and that account's usage pattern. It is the central control and it is a first-party data problem, not a vendor problem.
  • Evidence of delivery and consumption — dispatch receipt, delivery confirmation, service usage logs. It is what the chargeback circuit evaluates first.
  • Dispute rules and chargeback response — knowing the deadlines, the reason codes and the documentation each scheme accepts. Many cases are lost on procedure, not for lack of evidence.
  • Origination models and initial limits — for the credit variant, the control happens before granting, not after default.
  • Explicit commercial policy — return conditions, refund limits and clear communication of the charge on the statement. They reduce both abuse and good-faith disavowals.
  • Recognizable merchant descriptor on the statement — the simplest control on the list, and it resolves a real share of the disavowals that aren't fraud.
  • Step-up authentication on the operation — a biometric challenge or a second factor at the moment of the purchase or the signature. It doesn't stop the holder from operating, because the holder really is the holder. What it does is leave a record.
  • Logging and retention of the operation's evidence — what is kept, for how long and in what admissible format. It is an architecture decision made before any dispute.

Where a strong verification does contribute

The contribution is evidentiary and it is worth being precise about it, because it is the only honest connection between this fraud and an identity platform.

When a risk operation is confirmed with a biometric challenge, the organization stops having only a session log and starts having an element tied to the person: at that moment, on that device, for that operation. Faced with a disavowal, the difference between "the session was logged in" and "the person confirmed the operation with their face" is the difference between a presumption and proof.

Two limits worth stating. The evidence shows who carried out the operation, not with what intent, and there are legitimate claims where the holder did in fact operate. And in several markets in the region, consumer protection regulation assigns the burden of proof to the institution regardless of the technical evidence it holds; the evidence improves its position, it doesn't reverse the rule.

How VU approaches it

VU doesn't prevent first-party fraud, and no identity platform does. What it contributes is evidence of the moment of the operation.

Authenticate confirms risk operations with a biometric challenge instead of a password or a code, and that record ties the operation to the person and not only to the device or the session. It is the material with which a dispute is answered.

Frequently asked questions

It is the fraud committed by the legitimate holder of the account or the payment method. There is no impersonation and no stolen credentials: the person carries out a real operation and later disowns it, or deliberately fails to honor what they took on. The most common forms are disowning a purchase that was in fact made, intentionally defaulting on the first payment of a loan, and systematically abusing return policies.

In who carries out the operation. In impersonation, a third party passes themselves off as the holder and the effective control is identity: document verification, biometrics, liveness detection. In first-party fraud the holder is real and the verification correctly approves, because there is nothing to detect. That is why it is contained with behavior analytics, evidence of the operation and commercial policy, not with identity controls.

No. The identity was verified correctly and the real holder is the one who defrauds. What a biometric verification or authentication at the moment of the operation contributes is evidence: a record that this person, and no one else, confirmed that transaction. That changes the organization's position when the dispute arrives, without preventing the operation from happening.

In most payment schemes and in much of the region's consumer protection regulation, the burden falls on the merchant or the institution, not on the one who claims. That asymmetry is what makes first-party fraud effective, and it is the reason the evidence kept from the moment of the operation defines the outcome of the case.

One identity, one SDK

VU ONE brings identity verification, authentication and fraud protection together on a single identity graph.

The verification you run at signup stays available to authentication and to your fraud rules, with no repeated processes and no duplicated data.

Verify, Authenticate and Protect, consolidated in one place.

Request a demo