---
title: "Paying yourself vs paying someone else: first-party and third-party payouts"
seoTitle: "First-party vs third-party payouts: what changes"
description: "First-party payouts go to your own account, third-party payouts to someone else. What recipient_relationship changes: name checks, SWIFT docs, nesting."
date: "2026-10-05"
updated: "2026-10-05"
category: "payments"
author: "BlindPay Team"
faq:
  - q: "What is a first-party payout?"
    a: "A first-party payout sends money to a bank account owned by the same person or business that owns the funds, such as a company moving USDC into its own US checking account. On BlindPay you mark it with recipient_relationship set to first_party, and the beneficiary name has to match the customer's name."
  - q: "What is a third-party payout?"
    a: "A third-party payout sends money to someone other than the owner of the funds: a contractor, a supplier, a landlord, a family member. On BlindPay you pick the relationship that fits, such as vendor_or_supplier or independent_contractor. That skips the name-match check, and on SWIFT it adds a compliance document requirement."
  - q: "Do third-party SWIFT payouts need documents?"
    a: "Yes. Every SWIFT payout on BlindPay is created on_hold, and when the recipient relationship is anything other than first_party, the payout waits for a compliance document such as an invoice, purchase order, or contract. BlindPay's SWIFT reference says documents must be submitted within 30 days and are reviewed within 8 days."
  - q: "Do Pix, ACH, or SEPA payouts need documents for third parties?"
    a: "No. On BlindPay, payouts on rails other than SWIFT never wait for documents. You can still attach an optional document while the payout is processing, on hold, or completed, and it is shown to the compliance team without changing the payout's status. That's useful for large or unusual payments."
  - q: "Can I pay my customer's customers through my BlindPay account?"
    a: "Only if BlindPay can see them. Moving money for parties BlindPay has never onboarded or screened is nesting, which BlindPay prohibits. A third-party payout is fine when it settles your own customer's obligation. If your customer runs payments for its own client base, the compliant path is its own BlindPay instance."
---

A first-party payout goes to a bank account owned by the same person or business that owns the money. A third-party payout goes to anyone else: a contractor, a supplier, a landlord. On BlindPay the difference is one field, `recipient_relationship`, and it changes name checks, SWIFT document rules, and where the compliance line sits.

Most payout bugs around this field come from treating it as metadata. It isn't. It decides what the payout has to prove.

**Key takeaways**

- `recipient_relationship` is required on SWIFT, ACH, wire, and RTP bank accounts.
- `first_party` means the beneficiary name must match your customer. Any other value skips that name-match check.
- Every SWIFT payout starts `on_hold`. Third-party SWIFT payouts also wait for a compliance document.
- Other rails never wait for documents, but you can attach one.
- Paying for parties BlindPay can't see is nesting, whatever the relationship field says.

## What's the difference between a first-party and a third-party payout?

It's about who owns the destination account compared with who owns the funds.

| | First-party payout | Third-party payout |
| --- | --- | --- |
| Destination account owner | Your customer, the owner of the funds | Someone else |
| Typical example | A company cashing out USDC to its own US account | A company paying a supplier in Mexico |
| `recipient_relationship` | `first_party` | `employee`, `independent_contractor`, `vendor_or_supplier`, `subsidiary_or_affiliate`, `merchant_or_partner`, `customer`, `landlord`, `family`, or `other` |
| Name check | Beneficiary must match the customer | Name-match check skipped |
| SWIFT documents | Never required | Required before release |

Those are the accepted values per BlindPay's [bank accounts docs](/docs/bank-accounts). The field is required when you create SWIFT, ACH, wire, and RTP accounts. Note that `subsidiary_or_affiliate` is still third party: a sister company is a different legal entity, even inside the same group.

## What does `first_party` actually check?

That the account really is your customer's. When you set `first_party`, the beneficiary name has to match the customer record. On SWIFT, a mismatch fails with `beneficiary_name_must_match_customer_for_first_party` ([POBO and COBO](/docs/kb/pobo-cobo)).

The docs put it plainly: set `recipient_relationship` to anything other than `first_party` "to skip the name-match check". So a customer named John can pay an account belonging to Jack, as long as the relationship says what Jack is.

The tightest version of first party is a bank account connected through Plaid. BlindPay runs Plaid Identity Match between the bank's account holder and the customer record before creating the account, and a connected account held by someone else fails with `plaid_account_not_first_party`. Those accounts are always `first_party`.

Banks are moving the same way on their side. In the euro area, the Instant Payments Regulation made payment providers offer a verification-of-payee check on the payee's name and IBAN before the payer authorizes a transfer ([Regulation (EU) 2024/886](https://eur-lex.europa.eu/eli/reg/2024/886/oj)). [Verification of payee for instant payments](/resources/more/verification-of-payee-instant-payments) covers how those checks work country by country.

## Why do third-party SWIFT payouts need documents?

Because the bank on the other end wants to know why money is going to someone else. BlindPay creates every SWIFT payout `on_hold`. When the relationship isn't `first_party`, the payout also needs a document proving the relationship between the sender and the recipient, and it waits until compliance approves it.

Accepted types are `invoice`, `purchase_order`, `delivery_slip`, `contract`, `customs_declaration`, `bill_of_lading`, and `others`. The [SWIFT statuses reference](/docs/kb/swift-statuses) tracks progress in `tracking_documents`: `waiting_documents`, then `compliance_reviewing`, then approval. Documents must be submitted within 30 days of payout creation and are reviewed within 8 days of submission.

Two timing details matter for your flow. Documents are collected after the payout is created, not at quote time, so the 5-minute quote window is unaffected ([payout quotes](/docs/payout-quotes)). And the 100 USD SWIFT minimum applies either way.

[SWIFT POBO vs COBO](/resources/more/swift-pobo-vs-cobo-explained) goes deeper on whose name the beneficiary sees.

## What about Pix, ACH, SEPA, and other rails?

They never wait for documents. That holds for first-party and third-party payouts alike.

You can still attach a document voluntarily. BlindPay's payout docs let you call the same submission endpoint while a non-SWIFT payout is `processing`, `on_hold`, or `completed`. The document is stored on the payout and shown to compliance, and the payout's `status` and `tracking_documents` don't change. Uploading an invoice for an unusually large supplier payment is cheap insurance.

| Rail | Third-party allowed | Documents |
| --- | --- | --- |
| SWIFT | Yes | Required for any relationship other than `first_party` |
| ACH, wire, RTP | Yes | Optional, never blocks the payout |
| Pix, SEPA, and local rails | Yes | Optional, never blocks the payout |

## Illustrative example: how do three payouts from one company differ?

Illustrative example. A US software company holds 30,000 USDC and makes three payouts in a week.

| Payout | Destination | `recipient_relationship` | Amount | Extra steps |
| --- | --- | --- | --- | --- |
| 1 | Its own US checking account over ACH | `first_party` | 20,000 USDC | Beneficiary name must match the company |
| 2 | A contractor in Brazil over Pix | Not a Pix account field (Pix takes a name and a Pix key) | 3,000 USDC | None at payout time |
| 3 | A supplier in Germany over SWIFT | `vendor_or_supplier` | 6,500 USDC | Invoice upload, compliance review before release |

Total out: 20,000 + 3,000 + 6,500 = 29,500 USDC, leaving 500 USDC in the wallet.

Payout 3 is the one to plan around. The quote locks the rate and fees at creation, the payout sits `on_hold`, and the supplier is paid only after the invoice clears review. If your supplier expects the money on a date, upload the document the moment the payout is created.

## Where does a third-party payout become nesting?

When the money isn't really your customer's. BlindPay's [nested payments guide](/docs/kb/nested-payments) states the rule in one line: you may not use your account, wallet, or virtual account to move payments for any party whose identity or transaction activity BlindPay can't see.

A third-party payout is fine when it settles your customer's own obligation: its supplier, its contractor, its rent. It turns into nesting when your customer uses its account to pay for its own customers, who BlindPay has never onboarded or screened. The relationship field doesn't change that. `vendor_or_supplier` on a payment that's really a pass-through is still a pass-through.

The guide's quick test is worth running before you design a flow:

1. Do the funds belong to your entity?
2. Does the documentation match your entity name?
3. Is the beneficiary visible to BlindPay?
4. Are there multiple underlying parties behind this single payment?

If your customer needs to pay its own client base, the compliant path is its own BlindPay instance, at no extra setup cost per the guide.

## How do record-keeping rules fit in?

US funds-transfer rules ask financial institutions to keep the recipient's name, address, and account details on transfers of $3,000 or more ([31 CFR 1010.410](https://www.law.cornell.edu/cfr/text/31/1010.410)), and FinCEN publishes a Q&A on how that "travel rule" applies ([FinCEN](https://www.fincen.gov/resources/statutes-regulations/guidance/funds-travel-regulations-questions-answers)). That's one reason providers ask who the recipient is and how you know them.

For stablecoin legs, the [travel rule for stablecoin off-ramps](/resources/more/travel-rule-stablecoin-off-ramps) covers the thresholds and data. And [how to read an FX quote](/resources/more/how-to-read-an-fx-quote) helps you check the amount the third party will actually receive before you commit. Wrong bank details are a separate failure mode; [common stablecoin payout mistakes](/resources/more/stablecoin-payout-mistakes) lists those.

## What to do next

Audit the bank accounts you've already created: list every one with `recipient_relationship: first_party` and confirm the beneficiary really is your customer. Then read the document rules in the [POBO and COBO reference](/docs/kb/pobo-cobo) before your first third-party SWIFT payout.