Counterparties

A counterparty represents an entity that is external to the Layer2 ecosystem. Counterparties are used in deposit, withdrawal and payment (soon) operations to move funds between Layer2 accounts and the outside world.

A counterparty is made up of information related to:

A bank account or crypto wallet
The owner of said account / wallet

A counterparty contains information including:

Counterparty Type - Crypto , FIAT_US , FIAT_US_LINKED , FIAT_EU , FIAT_IN ...
Supported payment rails - Crypto, Fedwire (US), ACH (US), SEPA CT (EU), FPS (UK), SWIFT
Profile - name (account holder name), address (account holder address), line of business
Account information - account number, routing number, crypto wallet address, asset type, financial institution name and address

Counterparty Types

We separate counterparties into types based on where the counterparty is located. For example...

if an entity is located in the US, use the FIAT_US counterparty.
if an entity is located in the Great Britain (UK), use the FIAT_GB counterparty.
if an entity is located on a blockchain, use the CRYPTO counterparty.

Note:
For withdrawals, a counterparty represents where funds are being sent TO.
For deposits, a counterparty represents where funds are being received FROM.

📝 Example
Sending funds to India...
-> Select FIAT_IN as the counterparty type and provide relevant information relating to the bank account (and account holder) located in India.

Refer to the ‘Types, Asset Types and Rails’ page for a full breakdown of counterparty types and their supported payment rails.

Status

The field status is informs what state the counterparty is in and how it can be used.

Rules
Each status enforces rules as to what actions can be performed on a counterparty.

Read - is the counterparty information visible.
Update - can the counterparty information / status be updated.
Transact - can a customer send/receive funds with a counterparty.

Possible next status
A counterparty is limited by what status it can be set to based on their current status. E.g. a counterparty in FROZEN cannot be set to PENDING.

Status	Description	Rules	Possible Next Status
`ACTIVE`	Counterparty is fully operational.	Read ✅ Update ✅ Transact ✅	`EDD`, `DORMANT`, `CLOSED`, `FROZEN`
`CLOSED`	Counterparty is not operational. A counterparty cannot be updated from Closed status.	Read ✅ Update 🚫 Transact 🚫	No possible next status
`EDD`	Counterparty requires enhanced due dilligence. Counterparty is still operational.	Read ✅ Update ✅ Transact ✅	`ACTIVE`, `CLOSED`, `FROZEN`
`PENDING`	Counterparty is being AML checked.	Read ✅ Update ✅ Transact 🚫	`ACTIVE`, `CLOSED`
`FROZEN`	Counterparty is not operational until due dilligence checks are made.	Read ✅ Update ✅ Transact 🚫	`ACTIVE`, `CLOSED`, `EDD`
`DORMANT`	Counterparty is operational but has not been used in 12 months.	Read ✅ Update ✅ Transact ✅	`ACTIVE`, `CLOSED`, `EDD`

Layer2 Statuses
-> Statuses may have 'l2f' after the status e.g. PENDING_L2F. This means that the counterparty requires action by Layer2. Counterparties in these statuses can only be updated by Layer2.

Profile Types

The field profile_type is used to denote whether a counterparty is an Individual or a Corporation.

Asset Type Id (Currency)

The asset_type_id field indicates what is the currency or asset type of the counterparty's bank account / wallet. Asset type id does NOT relate to what is the currency of the source account (customer Layer2 account). Asset type id relates to the destination.

📝 Example
Sending funds to Mexico...
-> MXN (Mexican Peso) is the local currency of Mexico.
-> Select FIAT_MX as the counterparty type and FIAT_MAINNET_MXN as the asset type id.
-> The funds may leave from a customer's USD account but will settle in a MXN account in Mexico, hence asset type id = MXN.

For a comprehensive guide on the relationship between asset types and counterparty types, refer to the ‘Types, Asset Types and Rails’ page.

Creating a Counterparty

To create a counterparty, use the counterparties endpoint endpoint. Each counterparty must have a type e.g. FIAT_US, however the other mandatory fields for a counterparty is dependant on the counterparty type and rail selected. This is because the required information to use payment rails differs across payment rail. See ‘Types, Asset Types and Rails’.

-> e.g. the Fedwire payment rail requires institution_address, while ACH does not.

Once a type is selected, populate the rest of the counterparty's information including payment rail, personal information, and details relating to the account/wallet owned by the counterparty.