--- title: "Get trading provider by ID" method: GET path: "/trading/providers/{providerId}" tags: ["Trading"] --- # Get trading provider by ID `GET /trading/providers/{providerId}` ## Request - Base URL: `https://api.fireblocks.io/v1` - URL: `https://api.fireblocks.io/v1/trading/providers/{providerId}` - Auth: none declared - TypeScript: (a function with typed inputs; its response is checked against the schema) Retrieve a single provider by ID. **Endpoint Permission:** Owner, Admin, Non-Signing Admin, Signer, Approver, Editor, Viewer. For detailed information about error codes and troubleshooting, please refer to our [API Error Codes documentation](https://developers.fireblocks.com/reference/api-error-codes). ## Path parameters - `providerId` string, required ## Response `200` Single provider details. - union - AccountBasedAccessProvider: Provider integrated via Fireblocks connected accounts (`accountBased` is `true`). - `id` string, required: Unique identifier for the provider - `name` string, required: Display name of the provider - `logo` string: URL to the logo image of the provider - `accountBased` boolean, required: Indicates whether the provider access model is through accounts or directly - `manifest` Manifest, required: The manifest of the provider, describing its supported order, quote, and rate requirements. - `order` ManifestOrder, required: Defines requirements for the POST /orders endpoint. - `supported` boolean, required: Indicates whether the endpoint is supported by the provider - `participantsIdentificationPolicy` ParticipantsIdentificationPolicy: When present on a provider manifest, specifies KYC/AML identification requirements as JSON Schemas. `defaultSchema` is the baseline; `overrides` refine it by `asset`, `rail`, and/or `flowDirection` (see priority below). The most specific matching override applies its `schema` for that request context: it may fully replace `defaultSchema`, or partially override it—when the override `schema` is not provided as a complete standalone definition, fields and rules omitted there continue to follow `defaultSchema`. If this object is omitted from the manifest, the provider imposes no PII requirements through this policy. FirstParty participants are always exempt. Resolution: from overrides that match the request context, choose the most specific (most dimensions matched); break ties by earlier position in the `overrides` array; if none match, use `defaultSchema`. Priority (highest precedence first): 1. asset + rail + flowDirection 2. Any two dimensions: asset+rail, asset+flowDirection, rail+flowDirection 3. Any single dimension: asset, rail, or flowDirection 4. defaultSchema (no override matches) - `defaultSchema` string, required: A JSON Schema (draft-07) in string format that validates the ParticipantsIdentification object on requests where the provider manifest declares a `participantsIdentificationPolicy` for that endpoint (e.g. POST /orders). Defines which fields from originator and/or beneficiary are required. The schema uses oneOf to discriminate between INDIVIDUAL (PersonalIdentification) and BUSINESS (BusinessIdentification) entity types for each participant. For INDIVIDUAL: fullName, dateOfBirth, postalAddress, email, phone, idNumber, idType, etc. For BUSINESS: businessName, registrationNumber, postalAddress, email, phone, etc. If you constrain `idType` or `additionalIdType` with a JSON Schema `enum`, use the same values as `PersonalIdentificationType` (authoritative list in that schema). The example below mirrors that enum. The string content is expected to be valid JSON (application/json). - `overrides` IdentificationPolicyOverride[]: Contextual overrides scoped by asset, rail, and/or flowDirection. Most specific match wins; ties broken by array order. Replaces the default partially. Each override MUST include at least one of `asset`, `rail`, or `flowDirection` (not `schema` alone); see IdentificationPolicyOverride. - `asset` string: Fireblocks asset ID (fiat or crypto). - `rail` 'BLOCKCHAIN' | 'INTERNAL' | 'SWIFT' | 'IBAN' | 'US_WIRE' | 'ACH' | 'SEPA' | 'SPEI' | 'PIX' | 'LBT' | 'MOMO' | 'CHAPS' | 'PAYID' | 'INTERAC' | 'INTERNAL_TRANSFER' | 'CIPS' | 'NEQUI' | 'FPS_UK' | 'FPS_HK' | 'INSTA_PAY' | 'PESONET': Transfer rail: * **BLOCKCHAIN** - Transfer over the public blockchain * **INTERNAL** - Internal transfer within the same account (e.g. sub-accounts or same api key) * **SWIFT** - International wire transfer * **IBAN** - International Bank Account Number transfer * **US_WIRE** - Domestic wire transfer within the United States (e.g. FedWire) * **ACH** - Automated Clearing House transfer, typically takes longer but not as expensive as wire transfers * **SEPA** - Euro transfers within the SEPA zone * **SPEI** - Mexican interbank electronic payment system * **PIX** - Brazilian instant payment system * **LBT** - Local bank transfers * **MOMO** - Mobile money transfers (e.g. M-Pesa) * **CHAPS** - The Clearing House Automated Payment System (CHAPS) is a real-time gross settlement payment system used for transactions in the United Kingdom * **PAYID** - PayID payment identifier system (Australia) * **INTERAC** - Interac electronic funds transfer (Canada) * **INTERNAL_TRANSFER** - Internal transfer between accounts * **CIPS** - Cross-Border Interbank Payment System (China) * **NEQUI** - Nequi mobile payment (Colombia) * **FPS_UK** - UK Faster Payments (GBP) * **FPS_HK** - Hong Kong Faster Payment System (HKD) * **INSTA_PAY** - InstaPay instant payment (Philippines) * **PESONET** - PesoNet batch payment (Philippines) - `flowDirection` 'FIAT_TO_CRYPTO' | 'CRYPTO_TO_FIAT' | 'CRYPTO_TO_CRYPTO' | 'FIAT_TO_FIAT': The direction of asset conversion in an order. - `schema` string, required: A JSON Schema (draft-07) in string format that validates the ParticipantsIdentification object on requests where the provider manifest declares a `participantsIdentificationPolicy` for that endpoint (e.g. POST /orders). Defines which fields from originator and/or beneficiary are required. The schema uses oneOf to discriminate between INDIVIDUAL (PersonalIdentification) and BUSINESS (BusinessIdentification) entity types for each participant. For INDIVIDUAL: fullName, dateOfBirth, postalAddress, email, phone, idNumber, idType, etc. For BUSINESS: businessName, registrationNumber, postalAddress, email, phone, etc. If you constrain `idType` or `additionalIdType` with a JSON Schema `enum`, use the same values as `PersonalIdentificationType` (authoritative list in that schema). The example below mirrors that enum. The string content is expected to be valid JSON (application/json). - `supportedParties` ParticipantRelationshipType[]: The participant party types the provider supports for this endpoint. - `settlementTypes` SettlementTypeEnum[]: Supported settlement types when creating an order. If present - settlement is required. If absent - no need to provide settlement. - `executionTypes` ExecutionRequestDetailsType[], required: Supported execution types when creating an order. - `requiresReasonForPayment` boolean: Information about the source and purpose of the funds being transacted. Used by providers that require additional context for compliance and reporting. Provide this field when the provider manifest indicates it is required. - `quote` ManifestQuote, required: Defines requirements for the POST /quotes endpoint. - `supported` boolean, required: Indicates whether the endpoint is supported by the provider - `participantsIdentificationPolicy` ParticipantsIdentificationPolicy: When present on a provider manifest, specifies KYC/AML identification requirements as JSON Schemas. `defaultSchema` is the baseline; `overrides` refine it by `asset`, `rail`, and/or `flowDirection` (see priority below). The most specific matching override applies its `schema` for that request context: it may fully replace `defaultSchema`, or partially override it—when the override `schema` is not provided as a complete standalone definition, fields and rules omitted there continue to follow `defaultSchema`. If this object is omitted from the manifest, the provider imposes no PII requirements through this policy. FirstParty participants are always exempt. Resolution: from overrides that match the request context, choose the most specific (most dimensions matched); break ties by earlier position in the `overrides` array; if none match, use `defaultSchema`. Priority (highest precedence first): 1. asset + rail + flowDirection 2. Any two dimensions: asset+rail, asset+flowDirection, rail+flowDirection 3. Any single dimension: asset, rail, or flowDirection 4. defaultSchema (no override matches) - `defaultSchema` string, required: A JSON Schema (draft-07) in string format that validates the ParticipantsIdentification object on requests where the provider manifest declares a `participantsIdentificationPolicy` for that endpoint (e.g. POST /orders). Defines which fields from originator and/or beneficiary are required. The schema uses oneOf to discriminate between INDIVIDUAL (PersonalIdentification) and BUSINESS (BusinessIdentification) entity types for each participant. For INDIVIDUAL: fullName, dateOfBirth, postalAddress, email, phone, idNumber, idType, etc. For BUSINESS: businessName, registrationNumber, postalAddress, email, phone, etc. If you constrain `idType` or `additionalIdType` with a JSON Schema `enum`, use the same values as `PersonalIdentificationType` (authoritative list in that schema). The example below mirrors that enum. The string content is expected to be valid JSON (application/json). - `overrides` IdentificationPolicyOverride[]: Contextual overrides scoped by asset, rail, and/or flowDirection. Most specific match wins; ties broken by array order. Replaces the default partially. Each override MUST include at least one of `asset`, `rail`, or `flowDirection` (not `schema` alone); see IdentificationPolicyOverride. - `asset` string: Fireblocks asset ID (fiat or crypto). - `rail` 'BLOCKCHAIN' | 'INTERNAL' | 'SWIFT' | 'IBAN' | 'US_WIRE' | 'ACH' | 'SEPA' | 'SPEI' | 'PIX' | 'LBT' | 'MOMO' | 'CHAPS' | 'PAYID' | 'INTERAC' | 'INTERNAL_TRANSFER' | 'CIPS' | 'NEQUI' | 'FPS_UK' | 'FPS_HK' | 'INSTA_PAY' | 'PESONET': Transfer rail: * **BLOCKCHAIN** - Transfer over the public blockchain * **INTERNAL** - Internal transfer within the same account (e.g. sub-accounts or same api key) * **SWIFT** - International wire transfer * **IBAN** - International Bank Account Number transfer * **US_WIRE** - Domestic wire transfer within the United States (e.g. FedWire) * **ACH** - Automated Clearing House transfer, typically takes longer but not as expensive as wire transfers * **SEPA** - Euro transfers within the SEPA zone * **SPEI** - Mexican interbank electronic payment system * **PIX** - Brazilian instant payment system * **LBT** - Local bank transfers * **MOMO** - Mobile money transfers (e.g. M-Pesa) * **CHAPS** - The Clearing House Automated Payment System (CHAPS) is a real-time gross settlement payment system used for transactions in the United Kingdom * **PAYID** - PayID payment identifier system (Australia) * **INTERAC** - Interac electronic funds transfer (Canada) * **INTERNAL_TRANSFER** - Internal transfer between accounts * **CIPS** - Cross-Border Interbank Payment System (China) * **NEQUI** - Nequi mobile payment (Colombia) * **FPS_UK** - UK Faster Payments (GBP) * **FPS_HK** - Hong Kong Faster Payment System (HKD) * **INSTA_PAY** - InstaPay instant payment (Philippines) * **PESONET** - PesoNet batch payment (Philippines) - `flowDirection` 'FIAT_TO_CRYPTO' | 'CRYPTO_TO_FIAT' | 'CRYPTO_TO_CRYPTO' | 'FIAT_TO_FIAT': The direction of asset conversion in an order. - `schema` string, required: A JSON Schema (draft-07) in string format that validates the ParticipantsIdentification object on requests where the provider manifest declares a `participantsIdentificationPolicy` for that endpoint (e.g. POST /orders). Defines which fields from originator and/or beneficiary are required. The schema uses oneOf to discriminate between INDIVIDUAL (PersonalIdentification) and BUSINESS (BusinessIdentification) entity types for each participant. For INDIVIDUAL: fullName, dateOfBirth, postalAddress, email, phone, idNumber, idType, etc. For BUSINESS: businessName, registrationNumber, postalAddress, email, phone, etc. If you constrain `idType` or `additionalIdType` with a JSON Schema `enum`, use the same values as `PersonalIdentificationType` (authoritative list in that schema). The example below mirrors that enum. The string content is expected to be valid JSON (application/json). - `supportedParties` ParticipantRelationshipType[]: The participant party types the provider supports for this endpoint. - `settlementTypes` DVPSettlementType[]: Supported settlement types when requesting a quote. If present - settlement is required. If absent - no need to provide settlement. - `rate` ManifestBase, required: Base manifest schema with common properties - `supported` boolean, required: Indicates whether the endpoint is supported by the provider - `participantsIdentificationPolicy` ParticipantsIdentificationPolicy: When present on a provider manifest, specifies KYC/AML identification requirements as JSON Schemas. `defaultSchema` is the baseline; `overrides` refine it by `asset`, `rail`, and/or `flowDirection` (see priority below). The most specific matching override applies its `schema` for that request context: it may fully replace `defaultSchema`, or partially override it—when the override `schema` is not provided as a complete standalone definition, fields and rules omitted there continue to follow `defaultSchema`. If this object is omitted from the manifest, the provider imposes no PII requirements through this policy. FirstParty participants are always exempt. Resolution: from overrides that match the request context, choose the most specific (most dimensions matched); break ties by earlier position in the `overrides` array; if none match, use `defaultSchema`. Priority (highest precedence first): 1. asset + rail + flowDirection 2. Any two dimensions: asset+rail, asset+flowDirection, rail+flowDirection 3. Any single dimension: asset, rail, or flowDirection 4. defaultSchema (no override matches) - `defaultSchema` string, required: A JSON Schema (draft-07) in string format that validates the ParticipantsIdentification object on requests where the provider manifest declares a `participantsIdentificationPolicy` for that endpoint (e.g. POST /orders). Defines which fields from originator and/or beneficiary are required. The schema uses oneOf to discriminate between INDIVIDUAL (PersonalIdentification) and BUSINESS (BusinessIdentification) entity types for each participant. For INDIVIDUAL: fullName, dateOfBirth, postalAddress, email, phone, idNumber, idType, etc. For BUSINESS: businessName, registrationNumber, postalAddress, email, phone, etc. If you constrain `idType` or `additionalIdType` with a JSON Schema `enum`, use the same values as `PersonalIdentificationType` (authoritative list in that schema). The example below mirrors that enum. The string content is expected to be valid JSON (application/json). - `overrides` IdentificationPolicyOverride[]: Contextual overrides scoped by asset, rail, and/or flowDirection. Most specific match wins; ties broken by array order. Replaces the default partially. Each override MUST include at least one of `asset`, `rail`, or `flowDirection` (not `schema` alone); see IdentificationPolicyOverride. - `asset` string: Fireblocks asset ID (fiat or crypto). - `rail` 'BLOCKCHAIN' | 'INTERNAL' | 'SWIFT' | 'IBAN' | 'US_WIRE' | 'ACH' | 'SEPA' | 'SPEI' | 'PIX' | 'LBT' | 'MOMO' | 'CHAPS' | 'PAYID' | 'INTERAC' | 'INTERNAL_TRANSFER' | 'CIPS' | 'NEQUI' | 'FPS_UK' | 'FPS_HK' | 'INSTA_PAY' | 'PESONET': Transfer rail: * **BLOCKCHAIN** - Transfer over the public blockchain * **INTERNAL** - Internal transfer within the same account (e.g. sub-accounts or same api key) * **SWIFT** - International wire transfer * **IBAN** - International Bank Account Number transfer * **US_WIRE** - Domestic wire transfer within the United States (e.g. FedWire) * **ACH** - Automated Clearing House transfer, typically takes longer but not as expensive as wire transfers * **SEPA** - Euro transfers within the SEPA zone * **SPEI** - Mexican interbank electronic payment system * **PIX** - Brazilian instant payment system * **LBT** - Local bank transfers * **MOMO** - Mobile money transfers (e.g. M-Pesa) * **CHAPS** - The Clearing House Automated Payment System (CHAPS) is a real-time gross settlement payment system used for transactions in the United Kingdom * **PAYID** - PayID payment identifier system (Australia) * **INTERAC** - Interac electronic funds transfer (Canada) * **INTERNAL_TRANSFER** - Internal transfer between accounts * **CIPS** - Cross-Border Interbank Payment System (China) * **NEQUI** - Nequi mobile payment (Colombia) * **FPS_UK** - UK Faster Payments (GBP) * **FPS_HK** - Hong Kong Faster Payment System (HKD) * **INSTA_PAY** - InstaPay instant payment (Philippines) * **PESONET** - PesoNet batch payment (Philippines) - `flowDirection` 'FIAT_TO_CRYPTO' | 'CRYPTO_TO_FIAT' | 'CRYPTO_TO_CRYPTO' | 'FIAT_TO_FIAT': The direction of asset conversion in an order. - `schema` string, required: A JSON Schema (draft-07) in string format that validates the ParticipantsIdentification object on requests where the provider manifest declares a `participantsIdentificationPolicy` for that endpoint (e.g. POST /orders). Defines which fields from originator and/or beneficiary are required. The schema uses oneOf to discriminate between INDIVIDUAL (PersonalIdentification) and BUSINESS (BusinessIdentification) entity types for each participant. For INDIVIDUAL: fullName, dateOfBirth, postalAddress, email, phone, idNumber, idType, etc. For BUSINESS: businessName, registrationNumber, postalAddress, email, phone, etc. If you constrain `idType` or `additionalIdType` with a JSON Schema `enum`, use the same values as `PersonalIdentificationType` (authoritative list in that schema). The example below mirrors that enum. The string content is expected to be valid JSON (application/json). - `supportedParties` ParticipantRelationshipType[]: The participant party types the provider supports for this endpoint. - `connected` boolean, required: Whether the provider is currently connected. - `accounts` AccountBase[], required - `id` string, required: The ID of the account - `name` string, required: The name of the account - DirectAccessProvider: Provider used without per-account linking (`accountBased` is `false`). - `id` string, required: Unique identifier for the provider - `name` string, required: Display name of the provider - `logo` string: URL to the logo image of the provider - `accountBased` boolean, required: Indicates whether the provider access model is through accounts or directly - `manifest` Manifest, required: The manifest of the provider, describing its supported order, quote, and rate requirements. - `order` ManifestOrder, required: Defines requirements for the POST /orders endpoint. - `supported` boolean, required: Indicates whether the endpoint is supported by the provider - `participantsIdentificationPolicy` ParticipantsIdentificationPolicy: When present on a provider manifest, specifies KYC/AML identification requirements as JSON Schemas. `defaultSchema` is the baseline; `overrides` refine it by `asset`, `rail`, and/or `flowDirection` (see priority below). The most specific matching override applies its `schema` for that request context: it may fully replace `defaultSchema`, or partially override it—when the override `schema` is not provided as a complete standalone definition, fields and rules omitted there continue to follow `defaultSchema`. If this object is omitted from the manifest, the provider imposes no PII requirements through this policy. FirstParty participants are always exempt. Resolution: from overrides that match the request context, choose the most specific (most dimensions matched); break ties by earlier position in the `overrides` array; if none match, use `defaultSchema`. Priority (highest precedence first): 1. asset + rail + flowDirection 2. Any two dimensions: asset+rail, asset+flowDirection, rail+flowDirection 3. Any single dimension: asset, rail, or flowDirection 4. defaultSchema (no override matches) - `defaultSchema` string, required: A JSON Schema (draft-07) in string format that validates the ParticipantsIdentification object on requests where the provider manifest declares a `participantsIdentificationPolicy` for that endpoint (e.g. POST /orders). Defines which fields from originator and/or beneficiary are required. The schema uses oneOf to discriminate between INDIVIDUAL (PersonalIdentification) and BUSINESS (BusinessIdentification) entity types for each participant. For INDIVIDUAL: fullName, dateOfBirth, postalAddress, email, phone, idNumber, idType, etc. For BUSINESS: businessName, registrationNumber, postalAddress, email, phone, etc. If you constrain `idType` or `additionalIdType` with a JSON Schema `enum`, use the same values as `PersonalIdentificationType` (authoritative list in that schema). The example below mirrors that enum. The string content is expected to be valid JSON (application/json). - `overrides` IdentificationPolicyOverride[]: Contextual overrides scoped by asset, rail, and/or flowDirection. Most specific match wins; ties broken by array order. Replaces the default partially. Each override MUST include at least one of `asset`, `rail`, or `flowDirection` (not `schema` alone); see IdentificationPolicyOverride. - `asset` string: Fireblocks asset ID (fiat or crypto). - `rail` 'BLOCKCHAIN' | 'INTERNAL' | 'SWIFT' | 'IBAN' | 'US_WIRE' | 'ACH' | 'SEPA' | 'SPEI' | 'PIX' | 'LBT' | 'MOMO' | 'CHAPS' | 'PAYID' | 'INTERAC' | 'INTERNAL_TRANSFER' | 'CIPS' | 'NEQUI' | 'FPS_UK' | 'FPS_HK' | 'INSTA_PAY' | 'PESONET': Transfer rail: * **BLOCKCHAIN** - Transfer over the public blockchain * **INTERNAL** - Internal transfer within the same account (e.g. sub-accounts or same api key) * **SWIFT** - International wire transfer * **IBAN** - International Bank Account Number transfer * **US_WIRE** - Domestic wire transfer within the United States (e.g. FedWire) * **ACH** - Automated Clearing House transfer, typically takes longer but not as expensive as wire transfers * **SEPA** - Euro transfers within the SEPA zone * **SPEI** - Mexican interbank electronic payment system * **PIX** - Brazilian instant payment system * **LBT** - Local bank transfers * **MOMO** - Mobile money transfers (e.g. M-Pesa) * **CHAPS** - The Clearing House Automated Payment System (CHAPS) is a real-time gross settlement payment system used for transactions in the United Kingdom * **PAYID** - PayID payment identifier system (Australia) * **INTERAC** - Interac electronic funds transfer (Canada) * **INTERNAL_TRANSFER** - Internal transfer between accounts * **CIPS** - Cross-Border Interbank Payment System (China) * **NEQUI** - Nequi mobile payment (Colombia) * **FPS_UK** - UK Faster Payments (GBP) * **FPS_HK** - Hong Kong Faster Payment System (HKD) * **INSTA_PAY** - InstaPay instant payment (Philippines) * **PESONET** - PesoNet batch payment (Philippines) - `flowDirection` 'FIAT_TO_CRYPTO' | 'CRYPTO_TO_FIAT' | 'CRYPTO_TO_CRYPTO' | 'FIAT_TO_FIAT': The direction of asset conversion in an order. - `schema` string, required: A JSON Schema (draft-07) in string format that validates the ParticipantsIdentification object on requests where the provider manifest declares a `participantsIdentificationPolicy` for that endpoint (e.g. POST /orders). Defines which fields from originator and/or beneficiary are required. The schema uses oneOf to discriminate between INDIVIDUAL (PersonalIdentification) and BUSINESS (BusinessIdentification) entity types for each participant. For INDIVIDUAL: fullName, dateOfBirth, postalAddress, email, phone, idNumber, idType, etc. For BUSINESS: businessName, registrationNumber, postalAddress, email, phone, etc. If you constrain `idType` or `additionalIdType` with a JSON Schema `enum`, use the same values as `PersonalIdentificationType` (authoritative list in that schema). The example below mirrors that enum. The string content is expected to be valid JSON (application/json). - `supportedParties` ParticipantRelationshipType[]: The participant party types the provider supports for this endpoint. - `settlementTypes` SettlementTypeEnum[]: Supported settlement types when creating an order. If present - settlement is required. If absent - no need to provide settlement. - `executionTypes` ExecutionRequestDetailsType[], required: Supported execution types when creating an order. - `requiresReasonForPayment` boolean: Information about the source and purpose of the funds being transacted. Used by providers that require additional context for compliance and reporting. Provide this field when the provider manifest indicates it is required. - `quote` ManifestQuote, required: Defines requirements for the POST /quotes endpoint. - `supported` boolean, required: Indicates whether the endpoint is supported by the provider - `participantsIdentificationPolicy` ParticipantsIdentificationPolicy: When present on a provider manifest, specifies KYC/AML identification requirements as JSON Schemas. `defaultSchema` is the baseline; `overrides` refine it by `asset`, `rail`, and/or `flowDirection` (see priority below). The most specific matching override applies its `schema` for that request context: it may fully replace `defaultSchema`, or partially override it—when the override `schema` is not provided as a complete standalone definition, fields and rules omitted there continue to follow `defaultSchema`. If this object is omitted from the manifest, the provider imposes no PII requirements through this policy. FirstParty participants are always exempt. Resolution: from overrides that match the request context, choose the most specific (most dimensions matched); break ties by earlier position in the `overrides` array; if none match, use `defaultSchema`. Priority (highest precedence first): 1. asset + rail + flowDirection 2. Any two dimensions: asset+rail, asset+flowDirection, rail+flowDirection 3. Any single dimension: asset, rail, or flowDirection 4. defaultSchema (no override matches) - `defaultSchema` string, required: A JSON Schema (draft-07) in string format that validates the ParticipantsIdentification object on requests where the provider manifest declares a `participantsIdentificationPolicy` for that endpoint (e.g. POST /orders). Defines which fields from originator and/or beneficiary are required. The schema uses oneOf to discriminate between INDIVIDUAL (PersonalIdentification) and BUSINESS (BusinessIdentification) entity types for each participant. For INDIVIDUAL: fullName, dateOfBirth, postalAddress, email, phone, idNumber, idType, etc. For BUSINESS: businessName, registrationNumber, postalAddress, email, phone, etc. If you constrain `idType` or `additionalIdType` with a JSON Schema `enum`, use the same values as `PersonalIdentificationType` (authoritative list in that schema). The example below mirrors that enum. The string content is expected to be valid JSON (application/json). - `overrides` IdentificationPolicyOverride[]: Contextual overrides scoped by asset, rail, and/or flowDirection. Most specific match wins; ties broken by array order. Replaces the default partially. Each override MUST include at least one of `asset`, `rail`, or `flowDirection` (not `schema` alone); see IdentificationPolicyOverride. - `asset` string: Fireblocks asset ID (fiat or crypto). - `rail` 'BLOCKCHAIN' | 'INTERNAL' | 'SWIFT' | 'IBAN' | 'US_WIRE' | 'ACH' | 'SEPA' | 'SPEI' | 'PIX' | 'LBT' | 'MOMO' | 'CHAPS' | 'PAYID' | 'INTERAC' | 'INTERNAL_TRANSFER' | 'CIPS' | 'NEQUI' | 'FPS_UK' | 'FPS_HK' | 'INSTA_PAY' | 'PESONET': Transfer rail: * **BLOCKCHAIN** - Transfer over the public blockchain * **INTERNAL** - Internal transfer within the same account (e.g. sub-accounts or same api key) * **SWIFT** - International wire transfer * **IBAN** - International Bank Account Number transfer * **US_WIRE** - Domestic wire transfer within the United States (e.g. FedWire) * **ACH** - Automated Clearing House transfer, typically takes longer but not as expensive as wire transfers * **SEPA** - Euro transfers within the SEPA zone * **SPEI** - Mexican interbank electronic payment system * **PIX** - Brazilian instant payment system * **LBT** - Local bank transfers * **MOMO** - Mobile money transfers (e.g. M-Pesa) * **CHAPS** - The Clearing House Automated Payment System (CHAPS) is a real-time gross settlement payment system used for transactions in the United Kingdom * **PAYID** - PayID payment identifier system (Australia) * **INTERAC** - Interac electronic funds transfer (Canada) * **INTERNAL_TRANSFER** - Internal transfer between accounts * **CIPS** - Cross-Border Interbank Payment System (China) * **NEQUI** - Nequi mobile payment (Colombia) * **FPS_UK** - UK Faster Payments (GBP) * **FPS_HK** - Hong Kong Faster Payment System (HKD) * **INSTA_PAY** - InstaPay instant payment (Philippines) * **PESONET** - PesoNet batch payment (Philippines) - `flowDirection` 'FIAT_TO_CRYPTO' | 'CRYPTO_TO_FIAT' | 'CRYPTO_TO_CRYPTO' | 'FIAT_TO_FIAT': The direction of asset conversion in an order. - `schema` string, required: A JSON Schema (draft-07) in string format that validates the ParticipantsIdentification object on requests where the provider manifest declares a `participantsIdentificationPolicy` for that endpoint (e.g. POST /orders). Defines which fields from originator and/or beneficiary are required. The schema uses oneOf to discriminate between INDIVIDUAL (PersonalIdentification) and BUSINESS (BusinessIdentification) entity types for each participant. For INDIVIDUAL: fullName, dateOfBirth, postalAddress, email, phone, idNumber, idType, etc. For BUSINESS: businessName, registrationNumber, postalAddress, email, phone, etc. If you constrain `idType` or `additionalIdType` with a JSON Schema `enum`, use the same values as `PersonalIdentificationType` (authoritative list in that schema). The example below mirrors that enum. The string content is expected to be valid JSON (application/json). - `supportedParties` ParticipantRelationshipType[]: The participant party types the provider supports for this endpoint. - `settlementTypes` DVPSettlementType[]: Supported settlement types when requesting a quote. If present - settlement is required. If absent - no need to provide settlement. - `rate` ManifestBase, required: Base manifest schema with common properties - `supported` boolean, required: Indicates whether the endpoint is supported by the provider - `participantsIdentificationPolicy` ParticipantsIdentificationPolicy: When present on a provider manifest, specifies KYC/AML identification requirements as JSON Schemas. `defaultSchema` is the baseline; `overrides` refine it by `asset`, `rail`, and/or `flowDirection` (see priority below). The most specific matching override applies its `schema` for that request context: it may fully replace `defaultSchema`, or partially override it—when the override `schema` is not provided as a complete standalone definition, fields and rules omitted there continue to follow `defaultSchema`. If this object is omitted from the manifest, the provider imposes no PII requirements through this policy. FirstParty participants are always exempt. Resolution: from overrides that match the request context, choose the most specific (most dimensions matched); break ties by earlier position in the `overrides` array; if none match, use `defaultSchema`. Priority (highest precedence first): 1. asset + rail + flowDirection 2. Any two dimensions: asset+rail, asset+flowDirection, rail+flowDirection 3. Any single dimension: asset, rail, or flowDirection 4. defaultSchema (no override matches) - `defaultSchema` string, required: A JSON Schema (draft-07) in string format that validates the ParticipantsIdentification object on requests where the provider manifest declares a `participantsIdentificationPolicy` for that endpoint (e.g. POST /orders). Defines which fields from originator and/or beneficiary are required. The schema uses oneOf to discriminate between INDIVIDUAL (PersonalIdentification) and BUSINESS (BusinessIdentification) entity types for each participant. For INDIVIDUAL: fullName, dateOfBirth, postalAddress, email, phone, idNumber, idType, etc. For BUSINESS: businessName, registrationNumber, postalAddress, email, phone, etc. If you constrain `idType` or `additionalIdType` with a JSON Schema `enum`, use the same values as `PersonalIdentificationType` (authoritative list in that schema). The example below mirrors that enum. The string content is expected to be valid JSON (application/json). - `overrides` IdentificationPolicyOverride[]: Contextual overrides scoped by asset, rail, and/or flowDirection. Most specific match wins; ties broken by array order. Replaces the default partially. Each override MUST include at least one of `asset`, `rail`, or `flowDirection` (not `schema` alone); see IdentificationPolicyOverride. - `asset` string: Fireblocks asset ID (fiat or crypto). - `rail` 'BLOCKCHAIN' | 'INTERNAL' | 'SWIFT' | 'IBAN' | 'US_WIRE' | 'ACH' | 'SEPA' | 'SPEI' | 'PIX' | 'LBT' | 'MOMO' | 'CHAPS' | 'PAYID' | 'INTERAC' | 'INTERNAL_TRANSFER' | 'CIPS' | 'NEQUI' | 'FPS_UK' | 'FPS_HK' | 'INSTA_PAY' | 'PESONET': Transfer rail: * **BLOCKCHAIN** - Transfer over the public blockchain * **INTERNAL** - Internal transfer within the same account (e.g. sub-accounts or same api key) * **SWIFT** - International wire transfer * **IBAN** - International Bank Account Number transfer * **US_WIRE** - Domestic wire transfer within the United States (e.g. FedWire) * **ACH** - Automated Clearing House transfer, typically takes longer but not as expensive as wire transfers * **SEPA** - Euro transfers within the SEPA zone * **SPEI** - Mexican interbank electronic payment system * **PIX** - Brazilian instant payment system * **LBT** - Local bank transfers * **MOMO** - Mobile money transfers (e.g. M-Pesa) * **CHAPS** - The Clearing House Automated Payment System (CHAPS) is a real-time gross settlement payment system used for transactions in the United Kingdom * **PAYID** - PayID payment identifier system (Australia) * **INTERAC** - Interac electronic funds transfer (Canada) * **INTERNAL_TRANSFER** - Internal transfer between accounts * **CIPS** - Cross-Border Interbank Payment System (China) * **NEQUI** - Nequi mobile payment (Colombia) * **FPS_UK** - UK Faster Payments (GBP) * **FPS_HK** - Hong Kong Faster Payment System (HKD) * **INSTA_PAY** - InstaPay instant payment (Philippines) * **PESONET** - PesoNet batch payment (Philippines) - `flowDirection` 'FIAT_TO_CRYPTO' | 'CRYPTO_TO_FIAT' | 'CRYPTO_TO_CRYPTO' | 'FIAT_TO_FIAT': The direction of asset conversion in an order. - `schema` string, required: A JSON Schema (draft-07) in string format that validates the ParticipantsIdentification object on requests where the provider manifest declares a `participantsIdentificationPolicy` for that endpoint (e.g. POST /orders). Defines which fields from originator and/or beneficiary are required. The schema uses oneOf to discriminate between INDIVIDUAL (PersonalIdentification) and BUSINESS (BusinessIdentification) entity types for each participant. For INDIVIDUAL: fullName, dateOfBirth, postalAddress, email, phone, idNumber, idType, etc. For BUSINESS: businessName, registrationNumber, postalAddress, email, phone, etc. If you constrain `idType` or `additionalIdType` with a JSON Schema `enum`, use the same values as `PersonalIdentificationType` (authoritative list in that schema). The example below mirrors that enum. The string content is expected to be valid JSON (application/json). - `supportedParties` ParticipantRelationshipType[]: The participant party types the provider supports for this endpoint. - `approved` boolean: Whether the provider was approved for use - `hasTermsOfService` boolean, required: Whether the provider has terms of service - `termsOfServiceUrl` string: URL to the terms of service document - `privacyPolicyUrl` string: URL to the privacy policy document ## Other responses - `401`: Unauthorized. Missing / invalid JWT token in Authorization header. - `403`: Forbidden - insufficient permissions, disabled feature, or restricted access. - `404`: Provider not found. - `429`: Rate limit exceeded - slow down and retry later. - `5XX`: Internal error while processing the request. - `default`: Error Response --- [API](https://skmtc.dev/fireblocks/apis/fireblocks-api.md) - [All operations](https://skmtc.dev/fireblocks/apis/fireblocks-api/llms.txt) - [OpenAPI document](https://skmtc.dev/fireblocks/apis/fireblocks-api/revisions/4eba9965659a?raw)