SaFi Bank Space : Maker-Checker flow

Maker is BOFE user proposing change

Checker is Maker's supervisor reviewing the proposed changes

Maker-checker setup

• Each change in the BOFE is subject to the maker-checker process (there might be some exceptions, like selling new product) and ticket must be connected (manually copied Jira ticked ID in BOFE) with the requested change.

• Each maker has at least two checkers (direct supervisor and division supervisor), see IAM (OKTA) setup Create a bank user

• Each checker can be also maker (subject to the same approval process) by his supervisors, but top checker will not be maker, as he will not have any checker to review the changes.

• Maker can be in one, or part of multiple departments (cards, transactions), but still will have one direct supervisor (checker).

• Maker can view and edit (request changes) only in his department.

List of possible changes subject to maker-checker process (not exhaustive)

• Customer

  • Personal information - additional documents (certificates, legal documents) might be needed to be checked (manual process of checker).

    • Name

    • Date of birth

    • Place of birth

    • Age

    • Gender

  • Address

  • Contact information

    • Phone??

    • Email

• Subscription

  • Type

  • Waive

• Main account

  • Account name

  • Transaction changes

• Pockets

  • Pocket name

  • Pocket lock/unlock

  • Pocket closing

• Cards

  • Reordering lost card

  • Resolving emboss rejection

• Loans

• Overdrafts

• BNPL

• Transactions

  • Manual crediting / debiting

  • Transaction reversal

  • Transaction partial reversal

  • Resolving card dispute

Changes flow

1. New ticket (Jira)

• From callcenter by customer over phone (calling the callcenter)

  • Callcenter operator will create ticket with description and will choose the correct primary, secondary dispositions

  • From app (flagging transaction / dispute)

  • Automatic ticket creation via Automatic ticket creating from backend

• From system (possible fraud transaction flagged by system to be checked by BO) via Automatic ticket creating from backend

• Manual ticket creation in other cases, if necessary.

2. Ticket queue (Jira)

• All requests are properly inputed in Jira via issue submission UI. If originating from BOFE (button to submit ticket), the customer id (uuid) is propagated as well.

• New tickets (based on the disposition, e.g. transaction issues) are sorted in particular queues to be picked and assigned to makers by the supervisor.

• Maker will review the ticket, add notes, ask for additional info

3. Change request (BOFE)

• When ready, maker will edit the data and will fill in the ticket id (link the Jira issue)

• System will log the change, see: Maker-checker flows and along with the data, the list of checkers will be saved as well

4. Change notifications (BOFE)

• Checkers will be notified Checker notifications

5. Pending changes (BOFE)

• No new changes can’t be requested if previous are not cleared Show pending changes for particular tab/section

6. List of changes (BOFE)

• Checkers can view list of pending changes in Maker-Checker list

7. Resolving changes (BOFE)

• Checker can follow the ticket link and see the notes

• Checker can follow the link to appropriate customer / page to review

• Checker can resolve requested changes by either accepting or rejecting the change Checker change rejection / approval

8. Resolved notifications (BOFE)

• Maker will be notified Maker notifications

9. Closing tickets (JIRA)

• Checker will then close ticket, or move to appropriate stage in Jira manually

10. Auto-reject SM-3099 - Auto-reject all pending changes at the end of the day Done (SYSTEM)

• Requests that are not resolved in that business day, will be automatically closed

• Makers will be notified when the request is auto-rejected