The Slacker service is a bridge between SaFi microservices and the risk engine which consists of numerous GCP Serverless Cloud functions (or risk microservices in the future).
It provides three APIs:
Synchronous API to get advice about the operation being performed (accept, reject, …)
Event/Snapshot stream providing data from the services to the risk engine
Command API allowing risk functions to perform various actions using bank microservices
The synchronous and command API are part of the slacker-manager. The Event/Snapshot Stream is implemented using Kafka Connect framework.
Synchronous API
REST API documented and defined using OpenAPI. The services will ask Slacker using this API to get advice about the operation. It can be accepted, rejected, hold on or other operations can be requested. The input data and the answer is defined by the operation and needs to be agreed upon both with the service team and the risk.
The Slacker itself does not do any decisions. It receives data using REST API, asks risk serveless function to get the decision, and returns the answer. All the requests are logged but no PII is stored.
Allow or reject a transaction
For the Slacker PoC we are going to develop API for the transactions.
Please see Transactions - communication with Fraud & Risk Service (Slacker) to get an idea about implementation from the transactions team perspective. As input, we will get all the information which are sent to the TM in the posting instruction and all the rest of the data which can be interesting for the risk. See
The result will be sent as an enum. The list needs to be agreed with the risk, but we will use the following for the PoC: APPROVE, REJECT, STEPUP_NEEDED, MANUAL_APPROVAL_NEEDED.
Since this API is blocking it has to be as fast as possible.
Tasks:
Create a slacker-manager service
Design transaction API (create controller, DTOs and generate it automatically)
Agree on inputs and outputs with risk and transaction teams
Implement calling of the risk functions
Implement logging
Event/Snapshot Stream
This part of the Slacker converts existing Kafka messages emitted by services to Pub/Sub messages processable by the GCP Cloud functions.
Since we plan to use the Kafka Connect, it will not be part of the slacker-manager, but it will be independent.
The Slacker should not do any transformations of the messages there, however we need to discover the capabilities of the Kafka Connect to do that.
All the Kafka messages are encoded using Avro. We need to agree with the risk if it is ok or if we should do any conversion there.
Based on the requirements we need to decide if we are going to use the managed Kafka connect from Confluent or we are deploying and managing as our custom service.
Think about using https://github.com/GoogleCloudPlatform/pubsub/tree/master/kafka-connector
PoC - run the service and publish available Kafka messages
For the PoC we need to run the service either managed or in our GCP. We need to maintain a list of Kafka topics we are going to convert to Pub/Sub available to risk.
Tasks:
Configure and run Kafka Connect
Deploy Kafka Connect Pub/Sub plugin
Listen for the overdraft Kafka topic and publish using Pub/Sub
Create a simple data transformation (add, remove and modify message fields)
Agree on the data format with the risk and create a conversion if needed
If ready, listen and publish transactions Kafka topic
Command API
This Pub/Sub based fire and forget API provides various commands to the risk serverless functions.
The service listens on Pub/Sub topic and processes command messages. All the commands has to be processed, if it is not possible the command is redirected to a DLQ topic.
The message format has to be discussed with Risk, the available options are Avro, Probuf or JSON. In all the cases the messages are defined and checked using schema.
The Slacker itself is not performing any actions, it will just call the API of the service providing the requested action.
All the requests are logged.
PoC - create a service, listen at Pub/Sub and implement commands
For the PoC we need to implement and deploy the service and provide the command workflow (validation, DLQ and calling of the services). We will select the commands that are available at the moment at the service level.
Tasks:
Create a service
Create Pub/Sub topic and listen on it
Select command messages encoding method
Create command message schema
Implement DLQ
Implement commands
Create Jira ticket
Send user notification (text, push)
The manual approval of the transaction was done, approve/reject transaction