The Participant Lifecycle Bounded Context's primary concern regards anything to do with the management of a Participant within the Mojaloop Environment. When we are defining the Participant Lifecycle Management Bounded Context there are a few key concepts that should be clearly defined.
Maker-Checker Process
The Maker-Checker Process establishes the 6 eye verification and ensure that no write action takes place without being validated by some one with adiquite permissions. These permissions are defined by the Participant Lifecycle Management Bounded Context but are configurable and assignable as needed by the Scheme Rules. It is recommended that the users/roles that receive the maker permissions do not receive the checker permissions, and that the checker permissions are assigned to different users/roles. It will still be possible to assign both responsibilities to the same users/roles but this then voids the security that is provided by the maker-checker process that the system was built to support.
Participant States
The participant state management allows the admin operators to control permissions for a given participant based on their state. During the Platform Configuration phase, the Participant Lifecycle Management Bounded Context expects participant states to be defined and configured with either roles/permissions. The participant states can then be assigned to a given participant through the Participant Status Management process.
Terms with specific and commonly accepted meaning within the Bounded Context in which they are used.
Financial Service Provider that register on the Mojaloop ecosystem. Allowing said FSP to be able to transact with other Participants
Representative that is responsible for creating data structures through the use of request.
Representative that is responsible for approving and accepting data that has been requested to be created.
Functional Overview
Please review the common interfaces page to see how these interaction take place.
Use Case - Example REPLACE ME BC Workflow Diagram: Functional Overview
Create Participant (Single Step Registration)
The workflow provided by this UC enables the BC to employ a process through which to create a Participant on the Mojaloop ecosystem, this usually requires all the information that relates to the participant and the initial accounts needed.
Use Case - Create Pariticipant Initial UC - Create Participant Approve UC Workflow Diagram: Create Participant
The workflow provided by this UC enables the BC to employ a process through which to either withdraw or deposit funds to the Participant's account(s).
Use Case - Manage Funds - Initial Use Case - Manage Funds - Approve UC Workflow Diagram: Manage Funds
Update Endpoints
The workflow provided by this UC enables the BC to employ a process through which to update the endpoint of a given participant. When the request has been approved the endpoint will be called on a keep alive path to ensure connectivity.
Use Case - Update Endpoints - Initial Use Case - Update Endpoints - Initial UC Workflow Diagram: Update Endpoints
Update Participant Status
The workflow provided by this UC enables the BC to employ a process through which to change the status of a given participant to enforce different roles/scheme rules on the participant.
Use Case - Update Participant Status - Initial Use Case - Update Participant Status - Approve UC Workflow Diagram: Update Participant Status
Get Participant
The workflow provided by this UC enables the BC to employ a process through which to get information with about a given participant.
Use Case - Get Participant UC Workflow Diagram: Get Participant
Add Participant Accounts
The workflow provided by this UC enables the BC to employ a process through which to control different aspects of a Participant's accounts, from creating an account, enabling/disabling and updating the limits and threshold warnings of an account.
Update Participant Account Status (Enable/Disable)
Update Liquidity Limits and Warning Thresholds
Use Case - Add Participant Accounts - Initial Use Case - Add Participant Accounts - Approve UC Workflow Diagram: Add Participant Accounts
Liquidity Cover Reserve
The workflow provided by this UC enables the BC to employ a process through which to reserve liquidity cover for a Participant and notify the Accounts and Balances BC about the update.
Use Case - Reserve Liquidity Cover - Initial Use Case - Reserve Liquidity Cover - Approve UC Workflow Diagram: Liquidity Cover Reserve
Liquidity Threshold Exceeded
The workflow provided by this UC enables the BC to employ a process through which to notify the participant that a preset liquidity threshold has been reached and action might be required.
Use Case - Liquidity Threshold Exceeded UC Workflow Diagram: Liquidity Threshold Exceeded
Liquidity Limit Exceeded
The workflow provided by this UC enables the BC to employ a process through which to notify the participant when they have reached the preset liquidity limit of an account.
Use Case - Liquidity Limit Exceeded UC Workflow Diagram: Liquidity Limit Exceeded
Liquidity Threshold & Limit Reset
The workflow provided by this UC enables the BC to employ a process through which reset the liquidity limit or threshold notification checks when successful transfers have been executed and the participant account position is in a positive state.
Use Case - Liquidity Threshold & Limit Reset UC Workflow Diagram: Liquidity Threshold and Limit Reset
Liquidity Cover Query
The workflow provided by this UC enables the BC to employ a process through which to query the current liquidity of a participant account, along with additional read operations that are related to the participant's liquidity.
Use Case - Liquidity Cover Query UC Workflow Diagram: Liquidity Cover Queries
Canonical Model
Participant Accounts: Participants can only have one account per allowed currency. Update Position Use Case: Has been changed to the Manage Funds use case Maker/Checker Operations: Retry count has no effect on the way we process/re-process requests.
