Participant Lifecycle Management BC
Last updated
Was this helpful?
Last updated
Was this helpful?
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.
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.
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.
Participant
Financial Service Provider that register on the Mojaloop ecosystem. Allowing said FSP to be able to transact with other Participants
Maker
Representative that is responsible for creating data structures through the use of request.
Checker
Representative that is responsible for approving and accepting data that has been requested to be created.
Please review the common interfaces page to see how these interaction take place.
BC Workflow Diagram: Functional Overview
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.
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).
UC Workflow Diagram: Manage Funds
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.
UC Workflow Diagram: Update Endpoints
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.
UC Workflow Diagram: Update Participant Status
The workflow provided by this UC enables the BC to employ a process through which to get information with about a given participant.
UC Workflow Diagram: Get Participant
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.
Add Participant Account
Update Participant Account Status (Enable/Disable)
Update Liquidity Limits and Warning Thresholds
UC Workflow Diagram: Add Participant Accounts
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.
UC Workflow Diagram: Liquidity Cover Reserve
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.
UC Workflow Diagram: Liquidity Threshold 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.
UC Workflow Diagram: Liquidity Limit Exceeded
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.
UC Workflow Diagram: Liquidity Threshold and Limit Reset
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.
UC Workflow Diagram: Liquidity Cover Queries
Participant
id
participantAlias
endpointURL
state
Accounts[]
accountID
ledgerAccountType
accountCurrency
isActive
warningThreshold
limit
type
value
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.
