Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Universal financial industry message scheme
The ISO 20022 organization describes its purpose as "A single standardisation approach (methodology, process, repository) to be used by all financial standards initiatives".
The financial messaging standard can be defined as a set of messages that are used for exchanging a vast range of financial information data between organizations using:
A modelling methodology that captures, in a syntax-independent way, financial business areas, business transactions, and associated message flows
A central dictionary of business items used in financial communications
A set of XML and ASN.1 design rules to convert the message models into XML or ASN.1 schemas, whenever the use of ISO 20022 XML or ASN.1-based syntax is preferred
Impel's API platform offers all of the current 733 message definition version types, as well as all of the older versions too. Find the complete ISO 20022 message definitions schema list here.
Impel's API allows for instant settlement using digital assets
Impel's ISO 20022 API provides optional functionality that can instantly send a payment in the form of a digital asset "cryptocurrency" attached to the financial messages payload, at almost zero cost, to any counterparty's XDC Network wallet address.
Instant Settlement can be sent alongside a financial transaction and is used to instantly settle any accrued balance(s) as part of that transaction.
The instant settlement option uses the XDC Network's native coin XDC or XRC-20 tokens such as Fluent Finance's US+ stablecoin as a medium of value.
Cross-border and domestic payment rails leveraging blockchain DLT
Impel provides an ISO 20022 compliant financial messaging API that can be used by any institution anywhere (almost) in the world, such as a bank or corporate to send and receive financial data for either cross-border or regional payments. Our functionality can be used for bank to bank, bank to corporate or vice versa, or even corporate to corporate financial messaging.
Users of Impel's ISO 20022 API would still use nostro/vostro accounts and the Central Banking system to settle-up at the end of the day. The API is designed to be agnostic, allowing it to be a "plug and play" option to be plugged into core-banking systems.
Additionally, Impel takes it to the next level by allowing for optional instant settlement capability by including the functionality to add digital assets (cryptocurrency) such as a stablecoin like Fluent Finance's US+ or other asset types like XDC, the native coin on the XDC Network in the message's payload for instant settlement. This method adds tremendous value by eliminating the need for traditional nostro/vostro accounts and the Central Banking system. Settlement can take place in mere seconds 24x7x365, adding a significant time-advantage benefit for all involved.
Impel's ISO 20022 API uses the XDC Network's blockchain DLT protocol, an enterprise-grade, EVM-compatible Layer 1 network equipped with interoperable smart contracts. A highly optimized, bespoke fork of Ethereum, the XDC Network reaches consensus through a delegated proof-of-stake (XDPoS) mechanism, which allows for two-second transaction time, near zero gas fees, and over 2,000+ transactions per second (TPS). Secure, scalable, and highly efficient, the XDC Network powers a wide range of novel blockchain use cases. Learn more at the community-driven XDC Community, XDC Foundation, or at XinFin, the organization that created and maintains the XDC Network's protocol.
Right from the start, Impel's ISO 20022 API solution has been designed with great care and concern for delivering a high-level of security, as well as for being a fast and cost-efficient solution, and most importantly, to keep confidential transaction data private. The use of blockchain technology allows for a public recording of the transaction's date and timestamp, but keeps the actual financial message's data private.
An overview of Impel's ISO 20022 architecture and components can be found here.
Impel offers a self-paced ISO 20022 API demo that anyone can try
Anyone interested in seeing Impel's ISO 20022 financial messaging API operate in realtime over the XDC Network's blockchain DLT mainnet, can try a self-paced demo at anytime they choose.
An educational demnistrational environment has been setup to represent two pretend organizations, Bank A and Bank B that allows the user free-rein to create and send the financial message of their choice, allowing them the choose their own options that utilize the ISO 20022 PACS-009 and PACS-002 payment instructions.
Each demo user can create their own financial message with or without attaching a digital asset, such as XDC (the native coin to the XDC Network) or an XRC-20 token like Fluent Finance's US+ stablecoin in the messages payload for instant settlement.
To access Impel's self-paced demo, register for access first, then an email will be sent containing a non-sharable access link that can be used as many times as desired, so be sure to store the link in a safe memorable place for future access.
To register for demo access, click here.
User creates and sends an ISO 20022 standard (PACS 009) payment instruction from a pretend Bank A to a pretend Bank B counterparty.
View the transaction history of all the ISO 20022 financial messages that have been created by every registered demo user.
Reporting screen displays historical message data and the connected XDC Wallet(s) account balance.
Field | Description |
---|---|
To BIC*
Destination Bank Identification Code receiving financial message
To IBAN*
Destination International Bank Account Number
From IBAN*
Sending party's International Bank Account Number
Special Instructions
Text field for detailed commentary
Amount
Fiat amount to be transferred and currency type (USD, GBP, EUR)
Instant Settlement
Allows digital assets to be transferred in the ISO 20022 message's payload as collateral. Note: Price quote is good for 30 seconds, then refreshes based on current market value of the chosen digital asset. On the XDC Network's blockchain, funds are transferred from sender's digital asset wallet to the receiver's digital asset wallet.
Overview and schema of the ISO 20022 API's identity service
The identity service holds information about all of the gateway nodes operating on Impel's ISO 20022 API platform.
Operating as the brains of the ISO 20022 API, the identity service allows very gateway node the ability to accurately and securely route financial messages through Impel's platform from point A to point B by requesting data from other parties, like their BIC (Bank Identification Code), gateway URL, XDC wallet address, certificate, as well as providing the ability to move digital asset collateral from wallet to wallet.
When new gateway node is added to Impel's ISO 20022 API platform, it will be registered via the identity service.
Party | Description |
---|---|
BIC
Business Identifier Code
Name
Name of the entity
Gateway URL
The node's gateway URL
Certificate
Used when signing gateway messages
Address List
List of XDC wallet addresses
Network
The blockchain network where the wallet addresses reside, e.g. XDC Network)
Impel's ISO 20022 API uses Smart Contracts on the XDC Network
Because the XDC Network is a fork of Ethereum, it is EVM compatible and also allows for smart contract functionality. Impel's ISO 20022 API's smart contract. The smart contract stores all of the committed proofs and acts as an escrow until every participant approves the terms of the proof.
(1) When a proof is to be committed, one party gathers all info, requests signatures, and creates and commits a proof proposal (1), attaching collateral (if required).
(2) Then an event is published by the contract. Other participants can listen to this event and validate the proof proposal.
(3) If the validation is successful they can approve (2) the proposal, attaching collateral (if they should). If validation fails they can reject it.
(4) If the agreement is not met at specific designated time (defined by the creator) or if transaction is rejected, the attached collateral will be returned back to the sender.
Financial messages exchanged between parties may contain digital assets in the messages payload, therefore only the net settlement amount is exchanged between participants.
Impel's ISO 20022 API uses a Layer 2 security solution
Ethereum's documentation describes Layer 2 as follows:
Layer 2 is a collective term for solutions designed to help scale your application by handling transactions off the Ethereum Mainnet (Layer 1) while taking advantage of the robust decentralized security model of Mainnet.
Layer 2 solutions are built on top of a Layer 1 blockchain DLT protocol (like the XDC Network) to utilize security on a private layer to protect the data from being made public on the public decentralized blockchain. It also lowers transaction costs by combining multiple off-chain transactions into a single message, and also increases transaction speed with the use of data rollups.
Ethereum documentation lists the benefits:
Increased transactions per second greatly improve user experience, and reduce network congestion on Mainnet Ethereum
Transactions are rolled up into a single transaction to Mainnet Ethereum, reducing gas fees for users and making Ethereum more inclusive and accessible for people everywhere
Any updates to scalability should not be at the expense of decentralization or security – layer 2 builds on top of Ethereum
There are application specific layer 2 networks that bring their own set of efficiencies when working with assets at scale
Impel's API utilizes a tremendous strategy for sending ISO 20022 financial messages over the XDC Network through an API that permits advanced security and complex data handling. Furthermore, Impel's Layer 2 functionality allows financial messages to be sent without interruption or exposure to a third party.
Our ISO 20022 API's Layer 2 solution is a better fit for meeting the needs of financial institutions using our financial messaging platform, as we have a modified version of the state channels Layer 2 scaling pattern, allowing for a smarter, more secure solution.
The key aspects and components of Impel's ISO 20022 API
Send and receive financial messages between clients and other gateways
Committing message proofs onto the XDC Network's blockchain
Allowing digital assets such as the XDC Coin or US+ stablecoin to be included in the message's payload for instant settlement, without the need for traditional nostro/vostro accounts, nor the Central Banking system
Message
Proof
Event
Impel's ISO 20022 API is an event driven system that contains defined events
An event represents a lifecycle state of a message and proof object. Learn more about event (computing) here on Wikipedia.
Impel's ISO 20022 platform architecture explained in detail
Main components of Impel's ISO 20022 API:
Gateway Service
Identity Service
Smart contract functionality
Multiple messaging protocols
Together, all of these form a distributed, permissioned topology that leverages the XDC Network's blockchain DLT capabilities to meet modern application development requirements for financial messaging.
A Client is a software application's coding languages include Java, Typescript, C#; and uses Impel's ISO 20022 API to send and receive messages via a Gateway Service node. The Client sends a message to a Gateway Service node and then receives a responding message about subsequent processing events.
A Gateway Service is an Impel ISO 20022 platform node that is dedicated to and used by a single client application to process messages and events. The Gateway Service processes incoming and outgoing messages to/from a Client.
Messages are shared between Impel ISO 20022 Gateway Service nodes through message channels. A message channel is created for each Gateway Service node pair; exchanging messages with each other, in order to apply collateral netting on a Proof.
Message is one of the core domain models that holds information about financial messages like ISO 20022, and can optionally attach digital assets as collateral in the message's payload.
A Proof is a core domain model of Impel ISO 20022 platform and is used to group messages from a Message Channel between two platform nodes and to commit them onto the XDC Network's blockchain DLT in batches as a Proof.
The Identity Service is a service used as a registry of Impel's ISO 20022 platform nodes.
Impel's ISO 20022 API platform Smart Contract stores information about all the Proofs committed to the XDC Network's blockchain's DLT. It is also responsible for settling digital asset collateral between participants and acts as an escrow account.
A Client XDC Network wallet address is an account that stores digital assets (XDC or XRC-20 tokens like the US+ stablecoin) and used to send or receive the Proof's digital asset(s) as collateral.
Description | |
---|---|
id
Platform identifier
type
Type of an event e.g. (MESSAGE_CREATED, MESSAGE_SENT, etc.)
timestamp
Date/time event was created
subjectId
Identifier of a subject of the event
subjectType
Type of a subject of the event
data
Platform event serialized to JSON
The message component of Impel's ISO 20022 API
The message component is the primary object to house the financial message's data and optional digital asset information used for collateral that is passed from one gateway node to another gateway node, essentially getting the ISO 20022 financial message from point a to point b.
Impel's ISO 20022 API gateway service's message envelope utilizes cryptography, ensuring the following:
High throughput
Instant delivery
Guaranteed delivery
Secured delivery
State | Description |
---|---|
NEW
Initial state of the message
OUTBOX
Message is available to send to the counterparty
SENT
Message has been sent to the counterparty
RECEIVED
Message has been received by the counterparty
ACKNOWLEDGED
Message has been checked and validated
NOT_ACKNOWLEDGED
Message failed successful delivery
A gateway service processes messages and proofs. Upon lifecycle state change, a new event message is generated. Clients retrieve events from the gateway service endpoint which is polled periodically by a Client:
GET /api/gateway/iso20022/gateway/event
Event Types are defined in API definition
MESSAGE_CREATED
Description: Triggered by a sender node when message is successfully created.
MESSAGE_SENT
Description: Triggered by a sender node when message is sent to a counterparty node.
MESSAGE_RECEIVED
Description: Triggered by a recipient node when a message is received and successfully created on a counterparty node.
MESSAGE_ACKNOWLEDGED
Description: Triggered by both (sender/recipient) nodes when a message is acknowledged by a counterparty node.
MESSAGE_NOT_ACKNOWLEDGED
Description: Triggered by both (sender/recipient) nodes when a message is not acknowledged by a counterparty node
PROOF_CREATED
Description: Triggered by a sender node when a proof is successfully created.
PROOF_SENT
Description: Triggered by a sender node when proof was sent to a counterparty.
PROOF_RECEIVED
Description: Triggered by a recipient node when a proof is received and successfully acknowledged by a counterparty node.
PROOF_ACKNOWLEDGED
Description: Triggered by both nodes when a proof is acknowledged by counterparty node.
PROOF_NOT_ACKNOWLEDGED
Description: Triggered by both nodes when a proof is not acknowledged by a counterparty node.
PROOF_COMMITTED
Description: Triggered by both nodes when a proof is successfully committed.
PROOF_APPROVED
Description: Triggered by both nodes when a proof is successfully approved.
PROOF_REJECTED
Description: Triggered by both nodes when a proof is rejected.
The mechanics of Impel's ISO 20022 financial message
Impel's ISO 20022 API was designed to be message agnostic, meaning that it will house and send whatever data type the sender wants to send, MT or XML. The origination and fundamentals of the message that the client creates and sends to the gateway service that will be sent to the recipient that will be committed as a proof.
The data required to route message between gateways (sender, receiver).
SendMessageRequest data field requirements:
Sender
Recipient
Payload
Collateral (optional)
Validation
The AppHdr element is an ISO 20022 head message. Supported schemes:
head.001.001.01
head.001.001.02
head.001.001.03
AppHdr element:
The Document element is the actual ISO 20022 message e.g. PACS or PAIN.
The document schema attribute that points to the ISO 20022 schema type: urn:iso:std:iso:20022:tech:xsd:${MESSAGE_TYPE}
Example:
The ability to add a digital asset to the message's payload allows for instant settlement capability to where traditional nostro/vostro accounts and settling up at the end of the day with the Central Banking systems is no longer required.
Collateral is defined in SendMessageRequest by the optional collateral field.
Digital assets types supported:
NATIVE (XDC, the native coin to the XDC Network)
XRC-20 token (layer 2 projects)
Native XDC coin as collateral example:
XRC-20 token as collateral example:
All ISO 20022 message types and variants are candidates for validation. SendMessageRequest includes an optional flag "validatePayload" for validation.
ISO 20022 payload is validated by checking:
Document
AppHdr (optional)
Both elements has to be a valid ISO 20022 namespace, e.g.
urn:iso:std:iso:20022:tech:xsd:pain.002.001.03
urn:iso:std:iso:20022:tech:xsd:head.001.001.02
urn:iso:std:iso:20022:tech:xsd:pacs.002.001.12
Supplementary data is not supported by the platform.
Variable | Description |
---|---|
${HEADER_TYPE}
head.001.001.01 and head.001.001.02
${SENDER_BIC}
Sending party's BIC
${RECIPIENT_BIC}
Receiving party's BIC
${BUSINESS_IDENTIFIER}
Identification
${MESSAGE_TYPE}
pacs.009.001.10, pain.008.001.01, acmt.001.001.08, etc.
${MESSAGE_DATE}
Date the message was created
Impel's sandbox environment to spin-up and test gateway nodes
Impel's ISO 20022 platform provides an experimental environment that can be used for demonstration and testing purposes, as well as to help understand how the platform works.
The Sandbox environment provides two default gateway services, a pretend Bank A and Bank B, allowing a user to exchange ISO 20022 messages between Gateway Clients.
There are two different ways to interact with Impel's ISO 20022 API, allowing for exchanging of financial messages between clients and gateway services:
Postman
Terminal
Detailed explanation of Impel's ISO 20022 API message confirmation
A Proof is a confirmation of a received message that has been validated, acknowledged (signed) by counter party, before it will be committed as a transaction on the XDC Network.
Messages received through the gateway service will be committed to the blockchain after successful proof validation via the following procedure:
Selects a batch of uncommitted messages
Creates a proof
Collects signatures
Commits proof
Approves/Rejects proof
Step-by-step guide to use Postman for Impel's ISO 20022 API
In this article we will walk through exchanging ISO 20022 message on Impel ISO 20022 platform using Postman.
The provided Postman collection has defined a script which will authenticate all requests, which means that there is no need to supply an access token.
Postman Public Workspace has to be forked in order to send requests. To do that we have to fork a collection and environments to our private workspace.
First we have to select Impel ISO 20022 collection (1) and then click on a Fork button (2).
Next we have to set a name of the new fork (1), select a Workspace, e.g. "My Workspace" which is a default one for every user (2) and click on Fork button (3).
When collection is forked next step is to fork environments. In order to do that we have to select Environments from left menu (1), next click on the more options on the right side of environment name (2) and select Create a Fork (3). We have to create a fork for both environments. On "Create a Fork" form we have to set a name and a workspace, the same as when we fork collection.
Once everything is done we can go to the workspace in which we created forks.
The Postman Workspace has two available Gateway Services named, respectively, Party A and Party B. Each Gateway Service is a separate node in Impel's ISO 20022 platform.
First we need to select a Gateway Service, e.g. Party A (1).
Then choose Collections (2) from left menu and select Send message endpoint (3).
There are couple of examples for this endpoint, we will try with ISO 20022 message pain.002.001.03 (1).
We first have to copy the Body of the example and paste it in an endpoint request body (2). In the Body tab, we have to select the raw option (3) and then change its type to JSON (4). After that we can paste the example body into a request body window (5). Once that is done, we can click the Send button (6). In the response from the Gateway service we receive and messageId which is Impel ISO 20022 platform's identifier, which is set as global variable (gatewayMessageId) so later we can use GET endpoints without copying Gateway Message identifier - it will be set automatically.
Once Gateway Message is added in Impel ISO 20022 platform we can invoke "Get message" (1), with messageId (2) from the previous response. In order to do that we have to click the Send (3) button. A response will appear in the response window (4) with a body that is the same as the original Client Message.
Gateway Message can be fetched using the "Get message" endpoint (1). Once selected, we can click Send button (2) and check the response (3).
If the fullySigned flag is true (1) then we know that message was already signed by Party B and we can verify that. In order to do that we just have to change environment to Party B (2) and click the Send button (3), and then in a response window (4) we should see the same data as on Party A side.
Gateway Messages on both sides should be the same, the only differences are related to Gateway Message creation which is normal behavior.
To get a proof we have to change the Gateway Service back to Party A (1). Then we have to choose "Get message proof" (2) and click the Send button (3). After that we will see a response with Proof data (4).
If the fullySigned flag is true (1), then we know that proof was already signed by Party B and we can verify this by changing the Gateway Service to Party B (2) and clicking the Send button (3). In the response window (4) we should see the same data as on Party A side.
Proof on both sides should be the same, the only differences are related to Proof creation and status update which is a normal behavior.
Every state change in Impel ISO 20022 platform is stored as an event, e.g. Gateway Message created, Gateway Message sent, Gateway Message received and many more.
Events can be fetched using endpoint "Get events" (1), setting the correct endDateTime request param (2), clicking the Send button (3) and waiting for a response (4).
Impel ISO 20022 platform has a distributed architecture, meaning that each platform participant has to have its own gateway service (node) in a platform with dedicated identity provider (Keycloak).
New platform participant has to complete onboarding process:
Request for a dedicated node in a platform.
Generate API credentials (clientId/clientSecret).
Gateway service (node) exposes API which can be used to send messages and get information about them. It uses dedicated Identity Provider (Keycloak) to authenticate and authorize API requests. Gateway service requires JWT token on every requests, which can be obtained from Keycloak, from OpenID Connect token endpoint. In order to get JWT access token we need to first generate clientId/clientSecret.
With Initial Access Token we need to create Keycloak client by running below command:
Response example:
Extract client_id and client_secret fields. From now we can use these credentials to get OAuth2 JWT token from Identity Provider (Keycloak).
When you create a client through the Client Registration Service the response will include a registration access token. The registration access token (registration_access_token) provides access to retrieve the client configuration later, but also to update or delete the client. The registration access token is included with the request in the same way as a bearer token or initial access token. Registration access tokens are only valid once, when it’s used the response will include a new token.
Name | Description |
---|---|
Field | Description |
---|---|
Impel's ISO 20022 platform provides a , which allows users to call API endpoints in an easy and convenient way.
Sent Client Message request will be processed asynchronously by the platform and new s will be assigned Id as an identifier N.B. this can take a few seconds to create
Once a Gateway Message is processed by the system and acknowledged by a counterparty, a is created (it can take a few seconds to be created). We can wait few minutes after Gateway Message creation or try to get events using and search for an event related to the proof creation.
The returned EventDto structure is a wrapper for a proper event triggered in the Impel ISO 20022 Gateway service. In order to get a real event, we have to deserialize the content of the data field. The data field stores an event as a series of bytes, and is a JSON string of serialized events. The type of event is given in the type field. Using the type and event schema from the API definition, we can deserialize the content of an event to a proper data model. A full list of events types and their data schema is available in .
An application programming interface is a way for two or more computer programs to communicate with each other. It is a type of software interface, offering a service to other pieces of software. A document or standard that describes how to build or use such a connection or interface is called an API specification. (as per )
The following API endpoints are located at this URL:
To secure whole process, we use feature. That means that platform participants will generate API client credentials.
When new dedicated Gateway service is setup in a network, an email will be sent with .
Bank A Keycloak
https://auth-banka-sandbox.impel-lab577.co.uk/auth/realms/BBBBCAXXXXX client_id: gateway-api client_secret: UZbFa0uCD5NfaT9q
Bank B Keycloak
https://auth-bankb-sandbox.impel-lab577.co.uk/auth/realms/CCCCESXXXXX client_id: gateway-api client_secret: NiWaHZf8UmNYswWd
Bank A API
https://api-sandbox.impel-lab577.co.uk/BBBBCAXXXXX/api Authentication: OAuth2
Bank A API Swagger
Bank B API
https://api-sandbox.impel-lab577.co.uk/CCCCESXXXXX/api Authentication: OAuth2
Bank B API Swagger
messageIds
List of proof's messages platform identifiers
endToEndIds
List of proof's messages business identifiers
status
Status of a proof in the platform (CREATED, SENT...)
sender
Proof sender Party BIC
recipient
Proof recipient Party BIC
signature
Sender Party signature for a proof to send
counterpartySignature
Recipient Party signature for a received proof
channelHash
Hash of a proof's messages (hex format)
netSettlementCollaterals
Sum of proof's messages collaterals
Field
Description
ID
Message identifier
endToEndId
Message business identifier (extracted from ISO 20022 Business Application Header)
Status
Status of message (CREATED, SENT. etc.)
Direction
Message direction (INBOX, OUTBOX)
Sender
Message sender Party BIC (extracted from ISO 20022 Business Application Header)
Recipient
Message recipient Party BIC (extracted from ISO 20022 Business Application Header)
Signature
Sender Party signature for a message to send (base64 format)
counterpartySignature
Recipient Party signature for a received message (base64 format)
messageHash
Hash of a message (base64 format)
previousMessageHash
Hash of a previous message in a chain (base64 format)
Collateral
Information about message collateral
Type
Type of collateral, e.g NATIVE (XDC) or ERC20
Amount
Collateral amount
exchangePrice
Price of a collateral amount
exchangeCurrency
Currency of a collateral amount price
tokenSymbol
XRC-20 token symbol (e.g. US+)
Step-by-step guide to use Terminal for Impel's ISO 20022 API
This documentation walks through exchanging an ISO 20022 financial message on Impel's platform using curl commands to call its REST API. This is the same walk through as described in Postman article, but using terminal.
The Impel ISO 20022 Gateway Service endpoints are secured, so in order to call them we have to get an authentication token from the Keycloak service.
We then save the value of the access_token field from the received response, which we will use in further requests as the ${BANK_A_AUTH_TOKEN} variable.
We will then save the value of the access_token field from the received response, which we will use it in further requests as the ${BANK_A_AUTH_TOKEN} variable.
The Authentication token is only valid for 5 minutes. After that time a new token has to be requested, otherwise endpoints will throw an "unauthorized" exception with HTTP status code 401.
Once we have a valid authentication token, we can exchange a Client Message with our counterparty using the Impel ISO 20022 platform. In the example below, we will use the ISO 20022 pacs.009.001.10 message type.
The pacs.009.001.10 message has to be wrapped in a Client Message.
Save the value of the messageId field in the received response, we will use it later in further requests as ${MESAGE_ID} variable.
Sent Client Message will be processed by the platform and new Gateway Message will be created with messageId as identifier. It can take a couple of seconds to create it.
Once the Gateway Message is added in a platform we can get it back from a platform.
The Gateway Message model is fully described here.
If the fullySigned flag is true, we can check if the same Gateway Message exists on Party B side.
Gateway Message on both sides should be the same, the only differences are related to message creation which is a normal behavior.
Once a Gateway Message is processed by the system and acknowledged by the counterparty, the Proof is then created (though it can take a moment to be created). We can wait few minutes after Gateway Message creation or try to get events using get events endpoint and search for events related to proof creation.
If the fullySigned flag is true, we can check if the proof exists and it is the same on Party B side.
Proof on both sides should be the same, the only differences are related to Proof creation and status update which is a normal behaviour.
Every state change in the Impel ISO 20022 platform is stored as an event, e.g. Gateway Message created, Gateway Message sent, Gateway Message received and many more. All events can be retrieved using the endpoint below:
The returned EventDto model is just a wrapper for a proper event triggered in Impel ISO 20022 node. In order to get a real event we have to deserialize the content of the data field. The data field stores events as a sequence of bytes, which is a JSON string of serialized events. The type of an event is given in a type property. Using the type and event schema from API definition we can deserialize the content of an event to proper data model. A full list of events types and their data schema is available in Events Article.
Message id
Created
Ok
Ok
OK
The bank identification code (i.e. SWIFT/BIC)
Ok
Unique identifier for this party
Name of party
Swift BIC for this party
URL for this party's gateway
Base64 encoded certificate
Addresses for this party
XinFin address
The RSQL filter to apply as search criteria
The zero-indexed page number, optional
The page size, optional with default being 10
Ok
A filter to get events from given date
A filter to get events to given date
The zero-indexed page number
The page size
Ok
The RSQL filter to apply as search criteria
The zero-indexed page number, optional
The page size, optional with default being 10
Ok
Unique identifier for this party
Name of party
Swift BIC for this party
URL for this party's gateway
Base64 encoded certificate
Addresses for this party
XinFin address
Send message request
Message end to end id
Sender BIC
Recipient BIC
Message payload type
Message payload
Collateral
Collateral type, e.g. native XDC or ERC20 token
Collateral amount
Collateral exchange price
Collateral exchange currency
ERC20 token symbol, required when type is equal to ERC20
Flag which enables payload validation
Accepted
Message id
Message id
Ok
Proof status
Proof status change date time
Proof channel hash as hex
Sender BIC
Recipient BIC
Net settlement collaterals
Collateral type, e.g. native XDC or ERC20 token
Collateral net settlement amount
ERC20 token symbol
Flag which tells if all parties signed a proof
Initiator signature
Counterparty signature
Proof's messages identifiers
Proof's messages identifiers
Proof's messages end to end identifiers
Proof's messages end to end identifiers
Proof creation date time
Proof update date time
Message id
Flag if payload should be returned in a response
Ok
Message id
Message end to end id
Sender BIC
Recipient BIC
Message payload type
Message payload - returned only if requested
Collateral
Collateral type, e.g. native XDC or ERC20 token
Collateral amount
Collateral exchange price
Collateral exchange currency
ERC20 token symbol, required when type is equal to ERC20
Message status
Message direction (INBOX|OUTBOX) which tells if message was sent or received
Message hash
Previous message hash
Flag which tells if all parties signed a message
Initiator signature
Counterparty signature
Proof
Proof status
Proof status change date time
Proof channel hash as hex
Sender BIC
Recipient BIC
Net settlement collaterals
Collateral type, e.g. native XDC or ERC20 token
Collateral net settlement amount
ERC20 token symbol
Flag which tells if all parties signed a proof
Initiator signature
Counterparty signature
Proof's messages identifiers
Proof's messages identifiers
Proof's messages end to end identifiers
Proof's messages end to end identifiers
Proof creation date time
Proof update date time
Message creation date time
Message update date time
The RSQL filter to apply as search criteria
The zero-indexed page number, optional
The page size, optional with default being 10
The field to use for sorting
The sort direction, either ASC or DESC
Ok
Message id
Message end to end id
Sender BIC
Recipient BIC
Message payload type
Message payload - returned only if requested
Collateral
Collateral type, e.g. native XDC or ERC20 token
Collateral amount
Collateral exchange price
Collateral exchange currency
ERC20 token symbol, required when type is equal to ERC20
Message status
Message direction (INBOX|OUTBOX) which tells if message was sent or received
Message hash
Previous message hash
Flag which tells if all parties signed a message
Initiator signature
Counterparty signature
Proof
Proof status
Proof status change date time
Proof channel hash as hex
Sender BIC
Recipient BIC
Net settlement collaterals
Collateral type, e.g. native XDC or ERC20 token
Collateral net settlement amount
ERC20 token symbol
Flag which tells if all parties signed a proof
Initiator signature
Counterparty signature
Proof's messages identifiers
Proof's messages identifiers
Proof's messages end to end identifiers
Proof's messages end to end identifiers
Proof creation date time
Proof update date time
Message creation date time
Message update date time