A Task is created to track any update/create requests made to a resource e.g. Chaps Payments Controls in RTGS, except some exceptions which will result in a direct create/update. The task resource URL along with a "task id" is returned in response to the API call used to update/create resources.

The Bank of England RTGS Tasks API enables an organisation to:

• Retrieve a specific Task details

Below are the list of attributes that are retrieved for each Task.

Tasks Pattern:

Some of the RTGS APIs provide the POST, PUT and PATCH methods. Participants possess the ability to trigger a request for creating or amending resources from the API(s). Whenever a change is made through RTGS APIs, a Task is created. There are two types of Tasks in this design, depending on whether or not it requires approval by a user before the change is made in RTGS.

• Tasks which require approval, are called Multi Step Review Requests (MSR).
• Tasks which do not require MSR are simply referred to as Tasks, or Non-MSR Tasks.

Tasks which require MSR

For Tasks that require multi-step review the incoming request-type is used to cross reference the 'task configuration'. The resulting indicator will be 'stamped' on the task and for the lifecycle of that specific task, it will be bound by said indicator. Additionally, an 'expiration timestamp' will be stamped on the task (which is the timestamp of the current_value_day).

These Tasks introduce a series of 'lock' states to a task life cycle (ie: the task does not move directly from it's original 'SUBMITTED' state to the final 'COMPLETED' state). By providing additional states the capacity for alternative users to 'approve/reject' a request is introduced in addition to reverting a 'pending' task to the requester to make changes (however it's important to note there is a limit of 1 amendment for a given task. Should this limit be reached, the expected flow would be to cancel the request and start a new msr task). Ultimately, following the processing of the request, the task is moved to 'COMPLETED_SUCCESS' / 'COMPLETED_FAILED' / 'REJECTED'/ 'EXPIRED' and the underpinning resource is unlocked for processing, once more.

When Multi Step Review is enabled and the Participant has submitted the Update request via API channel, it mandates another user from the respective organisation to go to BERTI UI application and approve the Task requested via the API channel. In case Multi Step Review is enabled along with Dual Input required, the approver of the Task will have to key in the new values again. Dual Input Attempt field tracks the number of attempts when an approver performs blind dual input. Blind dual input is to allow an approver to input the same values as the requester without seeing what they have inputted. An approver has a total of 3 attempts to blindly input the same values as the initial API request post which the update request will be rejected.

The below diagram illustrates the 'finite state machine' of possible task-states which occur between a requester (a user updating/creating/deleting resource(s)) and a approver (a user ultimately approving/rejecting the aforementioned request)

Tasks which do not require MSR

For Tasks that do not require multi-step review the incoming request-type is used to cross reference the 'task configuration'. The resulting indicator will be 'stamped' on the task and for the lifecycle of that specific task, it will be bound by said indicator. These Tasks are expected to finish their lifecycle without human intervention. At first, the standard pattern (defined below) will create a 'Submitted' task, starting the task lifecycle (provided there's no pending task available). Next, within the CSE there will be another task created with the state 'Ready_For_Processing', before the miniservice will propagate downstream for processing. Ultimately, following the processing of the request, the task is moved to 'Completed_Success' / 'Completed_Failed' and the underpinning resource is unlocked for processing, once more.

The below diagram illustrates the 'finite state machine' of possible task-states

Filter Values:

The Tasks API has various fields thats have a predefined set of values e.g. Task Status Code, Priority etc. To retrieve the possible values of all these fields Participants can use the Filters API Get Resource by passing the relevant Resource Name of the field. For detailed information around fields thats have a predefined set of values across all RTGS API please refer to the following page Filter Values API.

Tasks API Use Cases & Benefits

• Near real-time tracking of Create/Update requests

• Promotes extra layer of protection and accountability

• Fuels innovation

• Promotes automation

• Reduction of manual effort

• Cost saving

• Improved user experience

Supported Developer Toolkit:

Bank of England RTGS APIs will be supported by Swift Microgateway and Swift SDK.Both solutions, provided by Swift, offer access to the APIs. Bank of England hosts a reference implementation based on Swift Microgateway and we can help you start with the API connectivity using this option.

If you are already a user of any of these solutions, just download the API Specification and follow the Swift recommended steps to import it into your implementation.