FSP Interoperability API BC
Last updated
Last updated
The FSP Interoperability API Bounded Context provides access to the internal operations and resources that the Mojaloop Ecosystem provides to a given Participant. This Bounded Context is responsible for providing a Participant with interfaces whit which the Participant can perform and execute tasks on Mojaloop. It is also responsible for providing communication back to the Participant regarding different notifications and system messages that a participant should expect to receive.
The FSP IOP API interacts with many different bounded contexts and thus the simplified view is provided here, for further reading on the events and connections that the FSP IOP API provides and consumes please review the Mojaloop Common Interfaces . The bounded contexts that are integrated with the FSP IOP API are:
Account Lookup & Discovery Bounded
Notifications and Alerts Bounded
Participant Lifecycle Management Bounded
Quoting\Agreement Bounded
Transfers Bounded
Settlement Bounded
FSP Interoperability API Functional Overview
Terms with specific and commonly accepted meaning within the Bounded Context in which they are used.
(D)FSP
(Digital) Financial Service Provider
Participant
Financial Service Provider (FSP) that has registered on the Mojaloop ecosystem. Allowing said FSP to be able to transact with other Participants
FSP IOP API
Financial Service Provider Interoperability Application Programming Interface, the API that provides access to functions and features of the Mojaloop Ecosystem.
Payer
The payer of electronic funds in a payment transaction.
Payer FSP
Payer's Financial Service Provider.
Payee
The recipient of electronic funds in a payment transaction.
Payee FSP
Payee's Financial Service Provider.
Use case definitions stipulated in the Open API for FSP Interoperability Specification have not been altered, and thus the Reference Architecture has been designed to only change the background orchestration of the internal Mojaloop services and Bounded Contexts.
Notifications pertain to ALL below use cases as a response to requests received in various forms. While the FSP IOP API is busy processing a request received, it might need to sends a request to the requesting DFSP or any other relevant DFSPs. The FSP IOP API will then query the Participant Lifecycle Management Bounded Context for the Callback URIs for the given participant that the notification needs to be sent to. The FSP IOP API will then send the notification request to the Notification and Alerts Bounded Context .
Associate transfer/s Participant/s and/or parties based on the POST Participant request (POST /participants/{Type}/{ID}). The FSP IOP API then sends a request to the Account Lookup & Discovery BC which will process the request and respond with a success event. The FSP IOP API then sends a notification PUT Participant response (PUT /participants/{Type}/{ID}).
Disassociate Participant/s and/or parties based on the DELETE Participant request (DELETE /participants/{Type}/{ID}). The FSP IOP API sends the request to the Account Lookup & Discovery BC to disassociate the party. The success response is then received by the FSP IOP API and then responds to the caller by sending a notification PUT Participant response (PUT /participants/{Type}/{ID}).
Retrieve participant information based on the GET Participant request (GET /participants/{Type}/{ID}) , which supplies the ID and structure. The FSP IOP API sends the request to the Account Lookup & Discovery BC to determine whether the desired participant exists. The FSP IOP API then responds to the requestor with a PUT Participant response (PUT /participants/{Type}/{ID}).
Retrieve party information based on the ID passed with the GET Party request (GET /parties/{Type}/{ID}). The FSP IOP API then sends a request to the Account Lookup & Discovery BC to determine the target FSP to forward the GET request to. The target FSP then responds with a PUT parties request. The information is then sent to the Account Lookup & Discovery BC to be cached before the PUT Party response (PUT /parties/{Type}/{ID}) is sent to the original sender of the GET request.
When a quote is sent using the POST Quote request (POST /quotes), the FSP IOP API will sends the request to the Quoting/Agreement BC to validate the quote. The FSP IOP API will then send the POST Quote to the Payee FSP, which in turn responds with a PUT Quote response (PUT /quotes/{ID}) and updated relevant information. The FSP IOP API sends the accepted quote to the The Quoting/Agreement BC to persist the quote information. The FSP IOP API will then forwards the PUT quote request to the Payer FSP and consider the quote successful.
This allows a FSP to get quote information of an existing quote. The GET Quote request (GET /quotes/{ID}) is sent to the FSP IOP API that queries the Quoting/Agreement BC for existing quotes. When the quote is retrieved the information is send back to the requesting FSP by sending the PUT Quote response (PUT /quotes/{ID}).
When a POST Quote request (POST /quotes) is , the FSP IOP API sends the request to the Quoting/Agreement BC for processing. The quote then fails validation the Quoting/Agreement BC responds with an error response that the FSP IOP API notifies the requesting FSP through the use of the PUT Quote Error response (PUT /quotes/{ID}/error).
When a POST Quote request (POST /quotes) is sent but the FSP IOP API sends the request to the Quoting/Agreement BC for processing and it cannot determine that both participants are valid FSPs then an error response is then sent to the FSP IOP API. The FSP IOP API then notifies the requesting FSP through the use of the PUT Quote Error response (PUT /quotes/{ID}/error).
When the Payer FSP sends a POST Quote request (POST /quotes) the FSP IOP API sends the request to the Quoting/Agreement BC for processing and the quote does not adhere to the scheme rules defined then an error response is then sent to the FSP IOP API. The FSP IOP API then notifies the Payer FSP through the use of the PUT Quote Error response (PUT /quotes/{ID}/error)
When the Payer FSP sends a POST Quote request (POST /quotes) the FSP IOP API sends the request to the Quoting/Agreement BC for processing and it succeeds initial processing. The FSP IOP API sends the request POST quote request to the Payee FSP. The Payee FSP should react with a accepted quote by sending PUT Quote request (PUT /quotes/{ID}). The response is sent to Quoting/Agreement BC for further processing and validation. When the Bounded Context detects that the quote does not adhere to the scheme rules defined then an error response is then sent to the FSP IOP API. The FSP IOP API then notifies both the Payer FSP and the Payee FSP through the use of the PUT Quote Error response (PUT /quotes/{ID}/error).
Agreement BC - Calculate Quote - Invalid Scheme Rules detected in Response
The Payer FSP sends a POST Transfers request (POST /transfers) to the FSP IOP API. The FSP IOP API then sends an event to the Settlements Bounded Context . The FSP IOP API waits for an event from the Transfers Bounded Context , to indicate that the transfer has been prepared, to send a POST request to the Payee FSP. The Payee FSP then responds with a PUT Transfers request (PUT /transfers/{ID}) (transferState = committed) to the FSP IOP API which in turn commits the transfer fulfillment. The PUT transfer is then send to the Payer FSP.
The Payer FSP sends a POST Transfers request (POST /transfers) to the FSP IOP API. The FSP IOP API then sends an event to the Settlements Bounded Context . The FSP IOP API waits for an event from the Transfers Bounded Context , to indicate that the transfer has been prepared, to send a POST request to the Payee FSP. The Payee FSP then responds with a PUT Transfers request (PUT /transfers/{ID}) (transferState = reserved) to the FSP IOP API which in turn reservers the transfer fulfillment. The PUT transfer is then send to the Payer FSP. The Payee FSP then receives a PATCH Transfers request (PATCH /transfers/{ID}) to notify the state change of the transfer.
Gets the transfer info based on the transfer ID used in GET Transfer request (GET /transfers/{ID}) and receives a PUT Transfers request (PUT /transfers/{ID}) to get the relevant information about the transfer.
POST Transfers request (POST /transfers) has already been processed and a status report is returned to the Payer FSP by receiving a PUT Transfers request (PUT /transfers/{ID}).
Transfers BC - Perform Transfer - Duplicate Post (Resend)
POST Transfers request (POST /transfers) has already been processed but no response is needed or requested.
The Payer FSP sends a POST Transfers request (POST /transfers) to the FSP IOP API. The Api then prepares the transfer and then sends the POST request through to the Payee FSP. The Payee FSP then declines the transfer by sending a PUT Transfer error request (PUT /transfers/{ID}/error) to the FSP IOP API. The FSP IOP API then notifies the Transfers Bounded Context that the transfer has been rejected and sends a PUT Transfer error request (PUT /transfers/{ID}/error) to the Payer FSP.
POST Transfers request (POST /transfers) gets rejected because the transfer timed out while funds are being prepared. The FSP IOP API sends a PUT Transfer error request (PUT /transfers/{ID}/error) request to the Payer FSP to notify of the error.
The Payer FSP sends a POST Transfers request (POST /transfers) to the FSP IOP API. The FSP IOP API then sends an event to the Settlements Bounded Context . The FSP IOP API waits for an event from the Transfers Bounded Context , to indicate that the transfer has been prepared, to send a POST request to the Payee FSP. The Payee FSP then responds with a PUT Transfers request (PUT /transfers/{ID}) (transferState = committed) to the FSP IOP API which in turn commits the transfer fulfillment. The transfer times out while/before the funds are committed and causes the transfer to be rejected. The FSP IOP API then notifies both the Payer and Payee FSPs with a PUT Transfer error request (PUT /transfers/{ID}/error).
The Payer FSP sends a POST Transfers request (POST /transfers) to the FSP IOP API. The FSP IOP API then sends an event to the Settlements Bounded Context . The FSP IOP API waits for an event from the Transfers Bounded Context , to indicate that the transfer has been prepared, to send a POST request to the Payee FSP. The Payee FSP then responds with a PUT Transfers request (PUT /transfers/{ID}) (transferState = committed) to the FSP IOP API which in turn commits the transfer fulfillment. The transfer times out after the funds are committed and causes the transfer to be rejected.
POST Transfers request (POST /transfers) has already been processed and a status report is returned to the Payer FSP by receiving a PUT Transfer error request (PUT /transfers/{ID}/error).
The Payer FSP sends a POST Transfers request (POST /transfers) to the FSP IOP API. The FSP IOP API then sends an event to the Settlements Bounded Context . The FSP IOP API waits for an event from the Transfers Bounded Context , to indicate that the transfer has been prepared, but receives a Liquidity check failure for the Payer FSP. The FSP OIP API then sends a PUT transfers error request to the Payer FSP to notify of the error.
The Payer FSP sends a POST Transfers request (POST /transfers) to the FSP IOP API. The Api then prepares the transfer and then sends the POST request through to the Payee FSP. The Payee FSP then declines the transfer by sending a PUT Transfer error request (PUT /transfers/{ID}/error) to the FSP IOP API. The FSP IOP API then notifies the Transfers Bounded Context that the transfer has been rejected and sends a PUT Transfer error request (PUT /transfers/{ID}/error) to the Payer FSP.
The Payer FSP sends a POST Transfers request (POST /transfers) to the FSP IOP API. The Transfers Bounded Context notifies the FSP IOP API that the Payer FSP is invalid. Depending on the reason for the Payer FSP being invalid the FSP IOP API will send a PUT Transfer error request (PUT /transfers/{ID}/error) to the Payer FSP.
The Payer FSP sends a POST Transfers request (POST /transfers) to the FSP IOP API. The Transfers Bounded Context notifies the FSP IOP API that the Payee FSP is invalid. The FSP IOP API will send a PUT Transfer error request (PUT /transfers/{ID}/error) to the Payer FSP to notify about the failure.
Many use cases stipulate that the request structure and semantics should be validated when receiving a event from an internal Bounded Context. This does not happen on a per request basis but rather is a requirement to be met when the building phase of the Reference Architecture is underway. What we are trying to say by showing that is that internally all events and available resources should be standardized and verified.
