WO2023111878A1

WO2023111878A1 - A system and method to determine and report the status of a deemed approved transaction

Info

Publication number: WO2023111878A1
Application number: PCT/IB2022/062184
Authority: WO
Inventors: Sarang Vinayak Bhoyar; Tittu Varghese; Vishal Anand Kanvaty
Original assignee: National Payments Corporation Of India
Priority date: 2021-12-17
Filing date: 2022-12-14
Publication date: 2023-06-22

Abstract

The present invention discloses a system (100) to determine and report the status of a deemed approved transaction. The system (100) is executed in each participating node of a blockchain network (10). A receiver module (102) of the system (100) generates a trigger command when a response to a transaction request is not received from a backend system of a receiver organization within a pre-defined time interval. A validation module (104) receives the trigger command and sends a transaction status check request, at pre-defined regular intervals of time, to the backend system of the receiver organization until the transaction response is received therefrom. A status transmitting module (106) communicates the received response to a sender node and the corresponding sender organization which generated the transaction request. The system (100) eliminates the need to wait till the end of a 'settlement cycle' to determine and report the status of 'deemed-approved' transaction.

Description

A SYSTEM AND METHOD TO DETERMINE AND REPORT THE STATUS OF A DEEMED APPROVED TRANSACTION

FIELD

The present disclosure generally relates to payment systems. More particularly, the present disclosure relates to a system and method to determine and report the status of a deemed approved transaction.

DEFINITIONS

As used in the present disclosure, the following terms are generally intended to have the meaning as set forth below, except to the extent that the context in which they are used indicate otherwise.

“Deemed Approved” payment transaction: The expressions ‘Deemed Approved payment transaction’ or ‘Deemed Approved transaction’ hereinafter refers to a pending payment transaction whose status is assumed to be ‘successful’ (i.e., amount paid to the beneficiary) by a central payment switch.

Blockchain Network: The expression “Blockchain Network” refers to a shared, immutable ledger that facilitates the process of recording payment transactions.

Node(s): The expression “node(s)” refers to electronic devices or peripheral devices, for instance, a computer, that participates in a blockchain network to perform payment transactions.

Participant Node(s): The expression ‘Participant Node(s)’ refers to a plurality of nodes that are permitted for communication to perform payment transactions.

Backend System: The expression ‘Backend system’ refers to a system executed in the background through an application programming interface (APIs).

Participating Organization: The expression “participating organization” refers to a sender participating organization and the receiver participating organization that communicates through the standard interface to perform payment transactions.

BACKGROUND The background information herein below relates to the present disclosure but is not necessarily prior art.

In current payment ecosystems, payment transactions between sender and receiver parties are switched by a centralized entity. A typical payment transaction involving a participant ‘A’ and a participant ‘B’ includes the steps of - (i) generating a transaction request by the participant ‘A’, (ii) sending the transaction request to a central switch, (iii) validating the transaction request by the central switch, (iv) forwarding the transaction request to the participant ‘B’, (v) processing the transaction request by the participant ‘B’, (vi) preparing a transaction response by the participant ‘B’, (vii) sending the transaction response to the central switch, (viii) validating the response by the central switch, (ix) forwarding the transaction response to the participant ‘A’, and (x) processing the response by the participant A.

All the parties involved in this transaction are confident of the correct status of the transaction if all the ten steps described above are executed successfully. When the sender (participant A) successfully receives the transaction response to its request, it can confidently conclude the status of the transaction, whether successful or failed, without any confusion.

But in certain instances, the central switch may not receive the transaction response from the receiver (participant ‘B’) in step no. (vii). Due to this, the central switch fails to conclude the actual status of the request that was sent to the receiver (Participant ‘B’). The transaction status can either be “processed successfully” or “failed”.

In case the transaction is successful, and the desired amount is paid to the beneficiary, but the central switch assumes that it is failed due to the lack of response from the receiver (Participant ‘B’) and informs the failure to the sender, the sender may end up returning the amount to the payer/customer, thereby resulting in the potential risk of not being able to recover that amount from either of the customers (payer or beneficiary).

In case the transaction is a failure and the beneficiary (customer of Participant B) is not paid the amount, the central switch may inform the uncertainty to the sender, the payer (customer of Participant ‘A’) would not know exactly what to do next - wait till confirmation (which can take many hours) or resend the amount (might end up paying twice). To handle such situations, typically, such pending transactions are considered to be “Deemed Approved”, which means the central switch assumes the transaction to be successful (i.e., the amount is paid to the beneficiary) and conveys the same “Deemed Approved” status to the sender (Participant ‘A’). The sender does not take any further action until the settlement cycle is complete. After the settlement cycle, the receiver (Participant ‘B’) updates the status of that transaction to the central switch and the required action (Debit Reversal or No Action) is taken offline. However, the receiver (Participant ‘B’) may take a longer time to report the correct status of the pending transaction to the central switch, which is not desired.

Therefore, there is a need for a system and method to determine and report the status of a deemed approved transaction that alleviates the above-mentioned drawbacks.

OBJECTS

Some of the objects of the present disclosure, which at least one embodiment herein satisfies, are as follows:

It is an object of the present disclosure to ameliorate one or more problems of the prior art or to at least provide a useful alternative.

An object of the present disclosure is to provide a system and method to determine and report the status of a deemed approved transaction.

Another object of the present disclosure is to provide a system and method to determine and report the status of a deemed approved transaction which reduces payment latency.

Still another object of the present disclosure is to provide a system and method to determine and report the status of a deemed approved transaction that reduces the risk of double payment transfer recovery.

Yet another object of the present disclosure is to provide a system and method to determine and report the status of a deemed approved transaction that reduces the period of transaction status uncertainty drastically from a few hours to a few minutes and sometimes even a few seconds.

Yet another object of the present disclosure is to provide a system and method to determine and report the status of a deemed approved transaction that reduces the possibility of disputes/ complaints being raised due to transaction status uncertainty and provides a better customer experience. Still another object of the present disclosure is to provide a system and method that does not wait till the end of a ‘settlement cycle’ to determine and report the status of a deemed approved transaction.

Other objects and advantages of the present disclosure will be more apparent from the following description when read in conjunction with the accompanying figures, which are not intended to limit the scope of the present disclosure.

SUMMARY

The present disclosure envisages a system to determine and report the status of a deemed approved transaction in a blockchain network. The blockchain network comprises a plurality of participating nodes. The system is implemented in each participating node of the blockchain network. The system comprises a receiver module, a validation module, and a status transmitting module. In an operative embodiment, the receiver module of an operative receiver node is configured to send a transaction request to a backend system of a receiver participating organization. The receiver module is further configured to generate a trigger command when a response to the transaction request is not received from the backend system of the receiver participating organization within a configurable pre-defined time interval. The validation module of the receiver node is configured to receive the trigger command and is further configured to generate and send a transaction status check request, at configurable pre-defined regular intervals of time, to the backend system of the receiver participating organization until the transaction response is received therefrom. The status transmitting module, of the receiver node, is configured to communicate the received response to a sender node corresponding to a sender participating organization which generated the transaction request, wherein the sender node relays the received response to a backend system of the sender participating organization.

In an embodiment, the sender node and the receiver node communicate with the backend systems of the sender participating organization and the receiver participating organization through standard interfaces. In another embodiment, the sender node and the receiver node communicate with the backend systems of the sender participating organization and the receiver participating organization through application programming interfaces (APIs). The present disclosure further envisages a method to determine and report the status of a deemed approved transaction in a blockchain network. The blockchain network comprises a plurality of participating nodes. The method comprises the following steps:

• sending, by a receiver module of an operative receiver node, a transaction request to a backend system of a receiver participating organization;

• generating, by the receiver module, a trigger command when a response to the transaction request is not received from the backend system of the receiver participating organization within a pre-defined time interval;

• receiving, by a validation module of the receiver node, the trigger command;

• generating, by the validation module, a transaction status check request;

• sending, by the validation module, the transaction status check request, at predefined regular intervals of time, to the backend system of the receiver participating organization until the transaction response is received therefrom;

• communicating, by a status transmitting module of the receiver node, the received response to a sender node corresponding to a sender participating organization which generated the transaction request; and

• relaying, by the sender node, the received response to a backend system of the sender participating organization.

The method is executed in each participating node of the blockchain network.

BRIEF DESCRIPTION OF THE ACCOMPANYING DRAWING

A system and method to determine and report the status of a deemed approved transaction of the present disclosure will now be described with the help of the accompanying drawing, in which:

Figure 1 illustrates a schematic view of a payment transaction between a sender party and a receiver party switched by a centralized entity, in accordance with the prior art;

Figure 2 illustrates a block diagram of a system to determine and report the status of a deemed approved transaction, in accordance with the present disclosure;

Figures 3A and 3B illustrate a schematic view of a payment transaction between a sender party and a receiver party using the system of Figure 2, in accordance with the present disclosure; and Figures 4A and 4B illustrate a flow diagram of a method to determine and report the status of a deemed approved transaction, in accordance with the present disclosure.

LIST OF REFERENCE NUMERALS

1A/1B - Participants/ Participant organizations

1C- Central switch

100 - System

102 - Receiver module

104 - Validation module

106 - Status transmitting module

10 - Blockchain network

10-A, 10-B, ... 10-N - Participant nodes

DETAILED DESCRIPTION

Embodiments, of the present disclosure, will now be described with reference to the accompanying drawing.

Embodiments are provided so as to thoroughly and fully convey the scope of the present disclosure to the person skilled in the art. Numerous details, are set forth, relating to specific components, and methods, to provide a complete understanding of embodiments of the present disclosure. It will be apparent to the person skilled in the art that the details provided in the embodiments should not be construed to limit the scope of the present disclosure. In some embodiments, well-known processes, well-known apparatus structures, and well-known techniques are not described in detail.

The terminology used, in the present disclosure, is only for the purpose of explaining a particular embodiment and such terminology shall not be considered to limit the scope of the present disclosure. As used in the present disclosure, the forms "a,” "an," and "the" may be intended to include the plural forms as well, unless the context clearly suggests otherwise. The terms “including,” and “having,” are open ended transitional phrases and therefore specify the presence of stated features, integers, steps, operations, elements and/or components, but do not forbid the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof. The particular order of steps disclosed in the method and process of the present disclosure is not to be construed as necessarily requiring their performance as described or illustrated. It is also to be understood that additional or alternative steps may be employed.

When an element is referred to as being "connected to," or "coupled to" another element, it may be directly connected or coupled to the other element. As used herein, the term "and/or" includes any and all combinations of one or more of the associated listed elements.

In current payment ecosystems, payment transactions between sender and receiver parties are switched by a centralized entity. A typical payment transaction involving a sender party, i.e., participant ‘ 1 A’ and a receiver party, i.e., participant ‘ IB’ is shown in Figure 1. The payment transaction includes the steps of - (1) generating a transaction request by the participant 1A, wherein the participant 1A is a financial entity associated with a payer, (2) sending the transaction request to a central payment switch/gateway 1C, (3) validating the transaction request by the central switch 1C, (4) forwarding the transaction request to the participant IB, wherein the participant IB is a financial entity associated with a payee, (5) processing the transaction request by the participant IB, (6) preparing a transaction response by the participant IB, (7) sending the transaction response to the central switch 1C, (8) validating the transaction response by the central switch 1C, (9) forwarding the transaction response to the participant 1A, and (10) processing the response by the participant 1A.

All the parties involved in this transaction are confident about the correct status of the transaction if all the ten steps described above are executed successfully. When the sender party (i.e., participant 1A) successfully receives the transaction response to its request, it can confidently conclude the status of the transaction, whether successful or failed, without any confusion.

But in certain instances, the central switch 1C may not receive the transaction response from the receiver party (i.e., participant IB) in step no. 7. Due to this, the central switch 1C fails to conclude the actual status of the request that was sent to the receiver party (Participant IB). The transaction status can either be “processed successfully” or “failed”.

In case the transaction is ‘successful’, and the desired amount is paid to the payee/beneficiary, but the central switch 1C assumes that it is failed due to the lack of response from the receiver party (Participant IB) and informs the failure to the sender party 1A, the sender party 1A may end up returning the amount to the customer/payer, thereby resulting in the potential risk of not being able to recover that amount from either of the customers (payer and payee/beneficiary).

In case the transaction is a failure, and the payee/beneficiary (customer of Participant IB) is not paid the transaction amount, the central switch 1C may inform the uncertainty to the sender party 1A, the payer (customer of Participant 1A) would not know exactly what to do next - wait till confirmation (which can take many hours) or resend the amount (might end up paying twice). To handle such situations, typically, such pending transactions are considered to be “Deemed Approved”, which means the central switch 1C assumes the transaction to be successful (i.e., the amount is paid to the beneficiary) and conveys the same “Deemed Approved” status to the sender party (Participant 1A). The sender party 1A does not take any further action until the settlement cycle is complete. After the settlement cycle, the receiver party (Participant IB) updates the status of that transaction to the central switch 1C, and the required action (Debit Reversal or No Action) is taken offline. The receiver party (Participant IB) may also take a longer time to report the correct status of the pending transaction, which is not desired.

In order to address the aforementioned problem, the present disclosure envisages a system (hereinafter referred to as “system 100”) and method (hereinafter referred to as “method 400”) to determine and report the status of a deemed approved transaction. The system 100 and method 400 are described with reference to Figure 2 through Figure 4B.

Figures 3A and 3B show a blockchain network 10 comprising a plurality of participant nodes (10A-10N). The blockchain network 10 is preferably a permissioned network such that only the participant nodes who have been approved by a Network Administrator can be made a part of the network 10. These nodes (10A-10N) are enabled to communicate with each other directly without any centralized entity/node. Each participant node (10A-10N) integrates closely with the backend systems of corresponding participating organizations. The participating organizations may be financial entities such as banks, Payment Service Providers (PSP), Application Service Providers (ASP), Prepaid Payment Instruments (PPIs), or any other centrally and/or government-regulated entity that is allowed to acquire customers and provide payment (credit/debit) services to the customers (individuals or entities). The network 10 further comprises a clearing house node (not shown) and a notary node (not shown). The clearing house node is the administrator node and it may be maintained by a clearing house. The notary node is a Unique Identification Authority of India (UIDAI) node that may facilitate biometric authentication.

The participant nodes (10A-10N) are configured to receive payment/transaction requests through standard interfaces or Application Programming Interfaces (APIs) from the backend systems of respective participating organizations. Each participant node (10A-10N) is configured to maintain its own ledger. The blockchain network 10 also has self-executing programs i.e., contracts containing a set of business rules which permit trusted transactions and agreements among the participant nodes (10A-10N).

Referring to Figure 2, the system 100 envisaged in the present disclosure is implemented in each participant node (10A-10N) of the blockchain network 10. The system 100 comprises a receiver module 102, a validation module 104, and a status transmitting module 106. In an operative embodiment, the receiver module 102, of an operative receiver node, is configured to send a transaction request to a backend system of a receiver participating organization. The receiver module 102 is further configured to generate a trigger command when a response to the transaction request is not received from the backend system of the receiver participating organization within a pre-defined time interval. The validation module 104, of the receiver node, is configured to receive the trigger command and is further configured to generate and send a transaction status check request, at pre-defined regular intervals of time, to the backend system of the receiver participating organization until the transaction response is received therefrom. The status transmitting module 106, of the receiver node, is configured to communicate the received response to a sender node corresponding to a sender participating organization which generated the transaction request. The sender node relays the received response to a backend system of the sender participating organization.

In one embodiment, the sender node and the receiver node communicate with the backend systems of the sender participating organization and the receiver participating organization through standard interfaces. Alternatively, the sender node and said receiver node communicate with the backend systems of the sender participating organization and the receiver participating organization through application programming interfaces (APIs). The method 400 envisaged in the present disclosure is executed in each participant node (10A-10N). Referring to Figures 4A and 4B, the method 400 comprises the following steps-

At step 402, a receiver module 102, of an operative receiver node of the network 10, sends a transaction request to a backend system of a receiver participating organization, wherein the transaction request is generated by a sender participating organization and sent to the receiver module 102 via an operative sender node of the network 10.

At step 404, the receiver module 102 generates a trigger command when a response to the transaction request is not received from the backend system of the receiver participating organization within a pre-defined time interval.

At step 406, the validation module 104 of the receiver node receives the trigger command from the receiver module 102.

At step 408, the validation module 104 generates a transaction status check request.

At step 410, the validation module 104 sends the transaction status check request, at predefined regular intervals of time, to the backend system of the receiver participating organization until the transaction response is received therefrom.

At step 412, the status transmitting module 106 of the receiver node communicates the received response to the sender node corresponding to the sender participating organization which generated the transaction request.

At step 414, the sender node relays the received response to a backend system of the sender participating organization.

In an exemplary embodiment, referring to Figures 3A and 3B, a backend system of a sender organization ‘1A’ generates a request for conducting a transaction (hereinafter ‘transaction request’) with a beneficiary organization. The sender organization’s backend system sends the generated transaction request to its participant node, node ‘10A’ in a blockchain network 10. The sender node ‘10A’ validates the transaction request and relays the request to a participant node corresponding to the beneficiary organization, i.e., receiver node ‘ 10B’. The receiver node ‘ 10B’ also validates the transaction request and forwards the validated request to a backend system of the beneficiary organization ‘ IB’. The beneficiary organization’s backend system ‘ IB’ processes the request and generates a response to the request. The beneficiary’s backend system then sends the generated response to its node ‘ 10B’. The node ‘ 10B’ validates the response. If the response is validated, the receiver node ‘ 10B’ sends the response to the sender node ‘ 10A’ which relays it to the sender’s backend system for further processing. However, if the node ‘ 10B’ does not receive the response to the transaction request from its backend system within a pre-defined time duration, it triggers a mechanism of ‘Transaction Status Check’ at regular intervals, as shown in Figure 3B, until it receives confirmed response from the receiver node’s backend system ‘ IB’. It then informs the latest status to the sender node ‘ 10 A’ that in turn passes it to its own backend system ‘ 1 A’.

An exemplary pseudo code depicting implementation of the method 400 of determining and reporting the status of a deemed approved transaction in a blockchain network 10 is as follows -

Do

{

Send transaction request to a backend system of a receiver organization;

}

If (transaction response received from the receiver backend system == YES)

{

Send the received response to a sender node corresponding to a sender participating organization that generated the transaction request; relay the received response to a backend system of the sender participating organization;

}

Else

{

Trigger generation of a transaction status check request; . . . STEP C

Send the generated transaction status check request at pre-defined regular intervals of time to the backend system of the receiver organization;

If (transaction response received from the receiver backend system == YES)

{

Send the received response to the sender node corresponding to the sender participating organization that generated the transaction request; relay the received response to the backend system of the sender participating organization;

}

Else

{

Return to Step C;

}

This process does not wait for the end of the ‘settlement cycle’ and hence reduces the period of uncertainty drastically (from a few hours to a few minutes and sometimes even a few seconds). This addressing of ‘Deemed Approved’ issues offers multiple benefits to participants viz. reduced risk of double transfer recovery, reduced disputes/ complaints raised due to transaction status uncertainty, and better customer experience.

Advantageously, the receiver module 102, the validation module 104, and the status transmitting module 106 may be implemented using one or more processor(s) of the nodes of the network. It can be understood that the node may be any kind of computing device, such as a computer, a laptop, or a server. The processor may be a general-purpose processor, a Field Programmable Gate Array (FPGA), an Application Specific Integrated Circuit (ASIC), a Digital Signal Processor (DSP), and/or the like. The processor may be configured to retrieve data from and/or write data to the memory. The memory may be, for example, a randomaccess memory (RAM), a memory buffer, a hard drive, a database, an erasable programmable read only memory (EPROM), an electrically erasable programmable read only memory (EEPROM), a read only memory (ROM), a flash memory, a hard disk, a floppy disk, cloud storage, and/or so forth.

The functions described herein may be implemented in hardware, software executed by a processor, firmware, or any combination thereof. If implemented in software executed by a processor, the functions may be stored on or transmitted over as one or more instructions or code on a computer-readable medium. Other examples and implementations are within the scope and spirit of the disclosure and appended claims. For example, due to the nature of software, functions described above can be implemented using software executed by a processor, hardware, firmware, hardwiring, or combinations of any of these. Features implementing functions may also be physically located at various positions, including being distributed such that portions of functions are implemented at different physical locations.

The foregoing description of the embodiments has been provided for purposes of illustration and is not intended to limit the scope of the present disclosure. Individual components of a particular embodiment are generally not limited to that particular embodiment, but, are interchangeable. Such variations are not to be regarded as a departure from the present disclosure, and all such modifications are considered to be within the scope of the present disclosure.

TECHNICAL ADVANCEMENTS

The present disclosure described herein above has several technical advantages including, but not limited to, the realization of a system and method to determine and report the status of a deemed approved transaction that:

• reduces payment latency;

• reduces the risk of double payment transfer recovery;

• reduces the period of transaction status uncertainty drastically from a few hours to a few minutes and sometimes even a few seconds;

• reduces the possibility of disputes/ complaints being raised due to transaction status uncertainty and provides a better customer experience; and

• that does not wait till the end of a ‘settlement cycle’ to determine and report the status of the deemed approved transaction.

The embodiments herein and the various features and advantageous details thereof are explained with reference to the non-limiting embodiments in the following description. Descriptions of well-known components and processing techniques are omitted so as to not unnecessarily obscure the embodiments herein. The examples used herein are intended merely to facilitate an understanding of ways in which the embodiments herein may be practiced and to further enable those of skill in the art to practice the embodiments herein. Accordingly, the examples should not be construed as limiting the scope of the embodiments herein.

The foregoing description of the specific embodiments so fully reveal the general nature of the embodiments herein that others can, by applying current knowledge, readily modify and/or adapt for various applications such specific embodiments without departing from the generic concept, and, therefore, such adaptations and modifications should and are intended to be comprehended within the meaning and range of equivalents of the disclosed embodiments. It is to be understood that the phraseology or terminology employed herein is for the purpose of description and not of limitation. Therefore, while the embodiments herein have been described in terms of preferred embodiments, those skilled in the art will recognize that the embodiments herein can be practiced with modification within the spirit and scope of the embodiments as described herein.

The use of the expression “at least” or “at least one” suggests the use of one or more elements or ingredients or quantities, as the use may be in the embodiment of the disclosure to achieve one or more of the desired objects or results.

While considerable emphasis has been placed herein on the components and component parts of the preferred embodiments, it will be appreciated that many embodiments can be made and that many changes can be made in the preferred embodiments without departing from the principles of the disclosure. These and other changes in the preferred embodiment as well as other embodiments of the disclosure will be apparent to those skilled in the art from the disclosure herein, whereby it is to be distinctly understood that the foregoing descriptive matter is to be interpreted merely as illustrative of the disclosure and not as a limitation

Claims

CLAIMS:

1. A system (100) to determine and report the status of a deemed approved transaction in a blockchain network (10), the blockchain network (10) comprising a plurality of participating nodes (10A-10N), the system (100) comprising:

• a receiver module (102), of an operative receiver node, configured to send a transaction request to a backend system of a receiver participating organization, said receiver module (102) further configured to generate a trigger command when a response to the transaction request is not received from the backend system of the receiver participating organization within a pre-defined time interval;

• a validation module (104), of the receiver node, configured to receive the trigger command, and further configured to generate and send a transaction status check request, at pre-defined regular intervals of time, to the backend system of the receiver participating organization until the transaction response is received therefrom; and

• a status transmitting module (106), of the receiver node, configured to communicate the received response to a sender node corresponding to a sender participating organization which generated the transaction request, wherein the sender node relays the received response to a backend system of the sender participating organization.

2. The system (100) as claimed in claim 1, wherein said sender node and said receiver node communicate with the backend systems of the sender participating organization and the receiver participating organization through standard interfaces.

3. The system (100) as claimed in claim 1, wherein said sender node and said receiver node communicate with the backend systems of the sender participating organization and the receiver participating organization through application programming interfaces (APIs).

4. The system (100) as claimed in claim 1, which is implemented in each participating node of the blockchain network (10). A method (400) to determine and report the status of a deemed approved transaction in a blockchain network (10), the blockchain network (10) comprising a plurality of participating nodes (10A-10N), the method (400) comprising the following steps:

• sending (402), by a receiver module (102) of an operative receiver node, a transaction request to a backend system of a receiver participating organization;

• generating (404), by said receiver module (102), a trigger command when a response to the transaction request is not received from the backend system of the receiver participating organization within a pre-defined time interval;

• receiving (406), by a validation module (104) of the receiver node, the trigger command;

• generating (408), by said validation module (104), a transaction status check request;

• sending (410), by said validation module (104), the transaction status check request, at pre-defined regular intervals of time, to the backend system of the receiver participating organization until the transaction response is received therefrom;

• communicating (412), by a status transmitting module (106) of the receiver node, the received response to a sender node corresponding to a sender participating organization which generated the transaction request; and

• relaying (414), by the sender node, the received response to a backend system of the sender participating organization. The method (400) as claimed in claim 5, which is executed in each participating node of the blockchain network (10).