Counterparties

A counterparty represents an entity that is external to the Rail ecosystem. Counterparties are used for deposita (ACH Pull only), withdrawas and (soon) payment operations.

For withdrawals , a counterparty represents where funds are being sent to
For deposits , a counterparty represents where funds are being received from (only applied to ACH Pull)

Counterparties are tied a specific customer, and currently cannot be shared across customers.

Creating a Counterparty

To create a counterparty, use the counterparties 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, see ‘Types, Asset Types and Rails’ for full details.

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

All newly created counterparties undergo AML screening prior to being available for use for transactions. See the status section below. Additionally, newly created counterparties will be subject to enhanced transaction screenings and RFIs.

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.

📝 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 counterparty status determines how it can be used.

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

Read - is the account information visible.
Update - can the account information / status be updated.
Transact - can an account be used to send/receive funds.

The counterparty is limited by what status it can be set to based on its 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`

Rail Statuses

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

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 Rail 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.