First-party payouts go to your own account, third-party payouts to someone else. What recipient_relationship changes: name checks, SWIFT docs, nesting.
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.on_hold. Third-party SWIFT payouts also wait for a compliance document.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. 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.
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).
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). Verification of payee for instant payments covers how those checks work country by country.
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 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). And the 100 USD SWIFT minimum applies either way.
SWIFT POBO vs COBO goes deeper on whose name the beneficiary sees.
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. 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.
When the money isn't really your customer's. BlindPay's nested payments guide 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:
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.
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), and FinCEN publishes a Q&A on how that "travel rule" applies (FinCEN). 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 covers the thresholds and data. And 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 lists those.
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 before your first third-party SWIFT payout.
Seven places blockchain payments beat bank rails: contractor payroll, remittances, B2B suppliers, marketplaces, 24/7 treasury, bill pay, and PSP payouts.
Push means the payer sends an ACH transfer. Pull means you debit a connected account. How each funds a USD to USDC on-ramp, the fees, and the return risk.
AP2, ACP, and x402 each verify that an AI agent had permission to spend. Here is what every protocol covers, who backs it, and the reconciliation gap none of them close.