Service Request Microservice (SRMS)

This brief guide describes the fully configurable Temenos API service request microservice (SRMS), a way for banks to action 'to do' requests for customers  - for example, Request a statement, or Request a cheque book. The servicing infrastructure provided by SRMS allows banks to define new request types, and associate mapping configurations for request fulfillment-related configurations. SRMS comes with an inbuilt virtual table concept, and uses document-based NoSQL DBs for capturing service requests. These requests are serviced in the respective fulfillment system.  

Architecture

A landing table is maintained by SRMS for each service request (type), when it is created. SRMS achieves a data addition pattern, where each table (service request type) has its own schema, created at runtime. The schema is validated at runtime as part of the POST request. An entry is created in the landing table/s for each request that is serviced.

Note: CRU (Create, Read, Update) operations are available for each service request (type). 

Maker-Checker

The maker-checker (or Maker and Checker, or 4-Eyes) authorization principle means that the customer's request must be approved by at least two individuals before it can be processed. Where a service request is raised by an internal user of the bank, another bank user is required to confirm/authorize the request.

A simple state change module is implemented to support the simple maker-checker process. The maker-checker process number of Approvals required parameters are configured as a part of the service request schema configuration.

Technical Design

A Store and Forward table captures the requests created by user/customer table. Once the approval process is completed, the raised request is maintained in the Maker- Checker table until it reaches the required number of approvals. On approval, the request is initiated.

SRMS Workflow

SRMS Lifecycle

Next Steps

• See SRMS API