Created by User 13e07, last modified by Lukas Civin on Nov 29, 2022

General intro to Slacker

Slacker is a Fraud-prevention tool acting as a middleman. Not really executing any strategies, the Slacker just push the request to the right place to do the work. Synchronously or Async, request or response, Master of Delegating and Orchestrating.

  • In general, most of the customer-initiated actions should go through Slacker synchronously: creating tx, taking a loan, etc. Slacker should respond immediately.

    • Possible responses from Slacker about a specific action could be: Approve, Reject, Step-up, On hold for BOFE investigation

  • Slacker also listens to various Kafka messages and will act asynchronously, if the Risk engine tells it to do so.

  • The ‘consequences’ of a Slacker decision should be managed by the domains, e.g. blocking an account, creating Jira ticket for BOFE, etc.

    • In case of a combination of blocks (e.g. block account and force-quit user at the same time), Slacker will orchestrate this sequence and call the respective domains.

Slacker’s requirements for the domains

Provide FE solution for all below scenarios (all domains)

  • The respective domains should manage all FE requirements and customer notifications.

  • FE language: there should be various explanations provided to the users for each situation, but AML/Risk will never publish all the details about a decision. So some sort of general explanations will be shared with the customers, and not the full truth.

Backoffice app (BOFE domain)

  • Create Jira tickets: https://jira-gateway.apps.dev.safibank.online/swagger/views/swagger-ui/# are created by Slacker automatically in case Risk decides to have a manual review (investigation) of the specific action. BO operators should take and use these tickets during the investigation.

  • Manage a transaction: Once a transaction is on hold during the investigation, Operators should approve/reject the transaction in BOFE, as well as ask for additional verification/stepup from the customer.

    • Jira tickets should not be linked to the actions on BOFE. E.g. if an operator is changing the status of a pending transaction on BOFE, the respective Jira ticket should not be automatically updated.

    • Customer notifications should be sent once a transaction was processed by the backoffice for the following instances:

      • Tx was approved

      • Tx was rejected

  • Manage an account: BOFE should be able to block/unblock an account. Please see the exact use case below in this document (Block/unblock user section)

  • Manage a user: BOFE should be able to block/unblock a user. Please see the exact use case below in this document (Block/unblock user section)

  • Create a transaction: Should operators create a transaction in BOFE, it should go through Slacker just as any other transaction would do. More details under the Transaction section of this page.

    • BOFE story for tx view:  SM-4149 - Flagged transactions in account tx view Done

    • BOFE tx reject/release:  SM-4150 - Flagged transaction reject/release Done

  • Manage an Amount: BOFE is required to block a specific amount on the customers' accounts, in case any governmental body is legally requesting SaFi to do so (unpaid taxes, etc.). Slacker is not involved in this scenario.

Block the login (IAM domain)

  • Force logout a user: Domain should be able to revoke the secret key in an async way. Immediate force logout customer is not possible. The customer can be locked out immediately when he makes any action (due to revoked key). Removal of key has two possible scenarios:

    • Delete key: light onboarding is necessary for the customer

    • Disable key: TBD what is expected from the customer to enable the key again

  • Related US

Block/unblock (or freeze/unfreeze) an account (Account domain)

Block/unblock a transaction (Transaction domain)

  • Flow: Transaction Fraud Check

  • AML view: https://safibank.atlassian.net/wiki/spaces/ITArch/pages/140214273

  • Manual approval tx: If a transaction is under investigation, the amount should be blocked on the balance until a manual response is done at BOFE.

  • Scheduled tx

    • Creating the schedule itself: Slacker will check and act if necessary

    • Processing a scheduled transaction on a regular basis: no Slacker involvement necessary

  • Pockets: No need to have Slacker verify transactions between the main account and pockets.

  • Offline tx: customer can not submit transactions while offline, so nothing to check for Slacker..

  • Manual tx by BOFE: should also go through Slacker just as a customer-initiated tx would.

Block/unblock personal data changes (Onboarding domain)

  • The requirement is to verify the customer’s changes in his/her profile in an asynchronous way, as follows:

    • Authentication level I (Low risk) = No check

    • Authentication level II (Medium I risk) = Passcode confirmation

    • Authentication level III (Higher risk) = Passcode confirmation + Face match check + Liveness Check

    • Authentication level IV (High risk) = Rejection

Stepup procedure (IAM domain)

Card transactions (Card domain)

  • Slacker will check all transactions, independently if Euronet/Mastercard/Visa already verified them or not. SaFi card team BO has a diagram describing the flow, we should link it here too. (MasterCard -> consortium data -> Euronet -> SaFi tr processing manager -> Slacker -> Google cloud function -> return info)

Frontend (app)

Async features provided to Slacker

  1. Jira ticketing (BO squad):   SM-3629 - Add createTransactionFraudTicket endpoint Done https://jira-gateway.apps.dev.safibank.online/swagger/views/swagger-ui/#

  2. Sending customer notifications

  3. Partial onboarding (revoking the key)

  4. Change status of an account

Sync feature provided to Slacker

  1. Workflows for all the above-mentioned use cases - transactions, onboarding/loans

  2. Stepup process: IAM Domain

EPFS Build Scope

  • The incoming and outgoing transactions need to go through Slacker via Rest API (sync call)

    • Intrabank tx will use only one call at the moment of initiating outbound tx, Slacker (the Risk function) will handle decisions for both sides (sending/receiving).

    • Slacker response will be either approve or reject or Step-up (specific type), and both BE and FE should act accordingly

      • In case of step-up: face comparison feature is the supported choice

  • Slacker will be able to receive and process commands (top-up notification, Jira ticket creation, change status of account, delete private key on user’s device)

  • Slacker Epic: SM-4560 - Slacker EPFS build Done

Attachments:

1f605@2x.png (image/png)
architecture_slacker (1).svg (image/svg+xml)