---
updatedAt: 2026-08-31T12:24:21.000Z
agentTools:
  projectIndex: https://docs.cybrid.xyz/llms.txt
---

# Counterparty Overview

What is a counterparty and how do I use one?

## What is a Counterparty?

A **counterparty** is an external individual or business that participates in financial transactions with your bank or customers. Counterparties represent the "other side" of a transaction—the recipients of payments or senders of funds.

Counterparties are:

* **External to your platform**: Not users of your application, but third parties involved in transfers
* **Identity-verified**: Undergo compliance screening (watchlist checks) to meet regulatory requirements
* **Associated with accounts**: Can have external bank accounts and/or external crypto wallets attached for receiving funds

## Counterparty Types

Counterparties can represent individuals or businesses.

| Type           | Description               | Examples                                        |
| -------------- | ------------------------- | ----------------------------------------------- |
| **Individual** | A person                  | Freelancers, family members, individual vendors |
| **Business**   | A company or organization | Suppliers, partners, corporate clients          |

## Ownership Types

Counterparties can be scoped to different levels of your organization.

| Scope              | Use Case                                           |
| ------------------ | -------------------------------------------------- |
| **Customer-owned** | A counterparty belonging to a specific customer    |
| **Bank-owned**     | A counterparty belonging to your bank/organization |

## Use Cases

* **Fiat transfers**: Send ACH, wire, RTP, FedNow or EFT payments to a counterparty's external bank account
* **Crypto transfers**: Send cryptocurrency to a counterparty's external wallet
* **Payment tracking**: Associate transfers with specific recipients for reporting and reconciliation
* **Compliance**: Maintain audit trails and satisfy travel rule requirements for transfers

## Counterparty vs. Customer

| Aspect                | Customer                          | Counterparty                     |
| --------------------- | --------------------------------- | -------------------------------- |
| Relationship          | Direct user of your platform      | External party in transactions   |
| Identity verification | Full KYC/KYB                      | Watchlist screening              |
| Accounts              | Platform accounts (fiat & crypto) | External bank accounts & wallets |
| Onboarding            | Complete user onboarding flow     | Created via API when needed      |

## Counterparty Model

The following examples show the structure of individual and business counterparty objects.

```json Individual Counterparty
{
  "created_at": "2024-09-19T23:36:58.367733Z",
  "updated_at": "2024-09-19T23:36:59.791494Z",
  "guid": "counterparty_guid",
  "type": "individual",
  "bank_guid": "bank_guid",
  "customer_guid": "customer_guid",
  "state": "verified",
  "labels": null,
  "compliance_decisions": [
    {
      "type": "person_watchlists",
      "state": "passed",
      "failure_codes": []
    }
  ]
}
```
```json Business Counterparty
{
  "created_at": "2024-09-23T16:51:12.669696Z",
  "updated_at": "2024-09-23T16:51:13.969713Z",
  "guid": "counterparty_guid",
  "type": "business",
  "bank_guid": "bank_guid",
  "customer_guid": "customer_guid",
  "state": "unverified",
  "labels": null,
  "compliance_decisions": [
    {
      "type": "business_watchlists",
      "state": "passed",
      "failure_codes": []
    }
  ]
}
```

### Counterparty States

| State        | Description                                                                                                                                                                                                                    |
| ------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `storing`    | Initial state immediately after creation. The counterparty record is being set up and stored in the platform. No compliance screening has occurred yet.                                                                        |
| `unverified` | The counterparty has been fully set up, but no compliance decisions exist yet, or previous decisions have expired or been invalidated. The counterparty may still be used for certain operations but has not passed screening. |
| `verified`   | The counterparty has an active, passing watchlist screening. Ready for use in transfers and payments.                                                                                                                          |
| `rejected`   | The counterparty has an active compliance decision that failed. Cannot be used for transactions until the issue is resolved.                                                                                                   |

### Compliance Decisions

An array of compliance decisions from counterparty verification. Each `compliance_decision` contains a `type`, `state`, and any `failure_codes` that may be returned.

#### Compliance Decision States

| State         | Meaning                                                                     |
| ------------- | --------------------------------------------------------------------------- |
| `passed`      | Watchlist screening passed—no matches found. Counterparty is verified.      |
| `failed`      | Watchlist screening failed—potential match found. Counterparty is rejected. |
| `expired`     | The decision has aged past its validity period and needs to be re-run.      |
| `invalidated` | The decision was manually invalidated (e.g., counterparty details changed). |

When a counterparty is rejected, the `compliance_decisions[].failure_codes` array contains the specific reasons.

## Key Behavioral Notes

* **Simpler verification**: Counterparty verification requires only watchlist checks—no KYC document verification, selfies, or other extensive checks
* **Expiring decisions**: The `expired_at` timestamp indicates when the decision becomes invalid. After expiration, the counterparty reverts to `unverified` and needs re-screening
* **Rejected counterparties blocked**: Rejected counterparties cannot participate in transfers
* **Multiple failure codes possible**: A single screening can identify multiple issues (e.g., both a watchlist match and PEP status)
* **Re-verification available**: If counterparty information is updated or time passes, you can trigger a new identity verification to potentially clear a previously rejected counterparty

## Counterparty Reuse in Fund Transfers

You can reuse an existing counterparty for multiple fund transfers, as long as they are the ultimate recipient of the funds. There is no need to create a new counterparty for each transfer if the recipient remains the same.

## Next Steps

* [Creating a Counterparty](https://docs.cybrid.xyz/docs/creating-a-counterparty)
* [Verifying a Counterparty](https://docs.cybrid.xyz/docs/verifying-a-counterparty)
* [Create Counterparty API Reference](https://docs.cybrid.xyz/reference/createcounterparty)