2021

Raast P2P – Back-office Functionality Document

Document Name: PSL Ref. IS-ITS-0521-05

Version: 2.0
Creation Date: 25th Nov 2021

This document and the information

contained herein are confidential.
Without Paysys’s prior written
permission, this document, either in
whole or in part, may not be
reproduced in any form or by any
means or disclosed to others.
 Revision History

Date Version Prepared By / Reviewed By Version Summary

Modified By

25th Nov 2021 2.0 M. Bilal Butt / M. Bilal Butt Version 2.0
Saad Khan

2
Contents
Revision History ........................................................................................................................... 2
1. Introduction ............................................................................................................................. 4
1.1 Annotation .................................................................................................................................... 4
2. Back-office Functionality .......................................................................................................... 5
2.1 Role Management ......................................................................................................................... 5
2.1.1 Role Creation/Modification .................................................................................................. 5
2.1.2 Screen Flows for Role Creation ............................................................................................. 6
2.1.3 Screen Flows for Role Modification ...................................................................................... 7
2.1.4 Role Authorization ................................................................................................................ 9
2.1.5 Screen Flows for Role Authorization .................................................................................. 10
2.2 User Management ...................................................................................................................... 11
2.2.1 User Creation/Modification ................................................................................................ 11
2.2.2 Screen Flows for User Creation/Modification .................................................................... 12
2.2.3 User Authorization ......................................................................................................... 13
2.2.4 Screen Flows for User Authorization ............................................................................. 14
3. Management Configuration .................................................................................................... 16
3.1 Daily Limit .................................................................................................................................... 16
3.1.1 Screen Flows for Limit Submission................................................................................. 16
3.1.2 Screen Flows for Limit Authorization............................................................................. 17
3.2 Transaction Fee Management .................................................................................................... 19
3.2.1 Screen Flows for Fee Submission ................................................................................... 19
3.2.2 Screen Flows for Fee Authorization ............................................................................... 20
4. Audit Logs .............................................................................................................................. 22
5. Return Payments .................................................................................................................... 24
5.1 Screen Flows for Return Payment Submission ........................................................................... 24
5.2 Screen Flows for Return Payment Authorization........................................................................ 26
6. SAF Details ............................................................................................................................. 27

3
1. Introduction

This document outlines the Open Connect portal features and user manual for banks operation and
settlement teams.

Banks team use this portal for batches and transaction detail’s view, reconciliation and reporting
purpose.

In addition to this, four new functionalities have also been added in back-office for ease of use.

1. Daily limit
2. Fee Management
3. Audit Logs
4. Return Payments

1.1 Annotation
Term Description Ownership
OC Open Connect Paysys Labs
MPG Micro payment Gateway SBP
UI User interface Bank
CBS Core Banking System Bank

4
2. Back-office Functionality

2.1 Role Management

2.1.1 Role Creation/Modification

Roles will define to set group of permissions which will be associated with users. Roles help to create
multiple users with same permissions. Administrator no need to select single permission every time
while creating users. Administrator only need to select role for that user.

By default, system has a super admin role.

Super admin role has only permission to create new admin user who will manage new roles and users
for application.

Role can be edit after creation as well. If any permission will be changed/updated for any role it will
be automatically reflected to all users having that role.

Changes will be applied upon approval by checker. Upon approving all users associated with selected
role will be updated.

User with Maker Role can access this page & can edit details which will be reflected once Checker Role
user approves it.

✓ User with role creation/modification rights login into back-office portal.

✓ User will navigate to role.

Menu -> User Management -> Role -> Add/Double click on role to Modify

✓ List of options available in OC portal for User to add or modify roles.

✓ User enter code, description and set status for role creation/modification.
✓ User selects from list of permissions to add or revoke given rights from respective role.
✓ User submit request to checker for review and approve.

5
2.1.2 Screen Flows for Role Creation

➢ User left click on "Role” in Micro Payment Gateway Module Backoffice Dashboard.

+
Click on “ ” button on top right corner of the screen.

➢ A new side screen will appear. From there you can Add Role by providing some parameters
like Code, Description and Status, and also assign permissions for that role.

6
 ➢ After filling all required parameters and permissions click on “Submit” button so that the role
creation request would be moved to checker bucket for authorization.

2.1.3 Screen Flows for Role Modification

➢ User left click on "Role” in Micro Payment Gateway Module Backoffice Dashboard.

7
➢ User left double click on any created role or also use filters to search for created roles.

➢ A new side screen will appear from there you can edit/modify any permission in that role.
Then user left click on “Submit” button, so that the request would be forwarded to checker
bucket for authorization.

8
2.1.4 Role Authorization

User having Checker rights login into OC portal.

✓ Checker clicks on “Inbox” from dashboard to check pending requests.

✓ List of pending requests appeared on checker screen.

List contain following details:

o Process Id (System generated Id)

o ID/Code
o Name/Desc
o Created By/Modified By
o Operation
o Comments
o Request Date
✓ Checker clicks on request to view role details and permissions.
✓ Checker review role and have following options:

o Approved
o Reject

✓ Checker can select any of above option and input remarks.

✓ On approval role will be approved and available to bind with users.
✓ On rejection role request will be return to maker with checker remarks.
✓ Maker can view return requests in a separate menu with checker comments.
✓ Maker can do the necessary changes and sent back request to checker for approval.
✓ Same process for checker will be followed.

9
2.1.5 Screen Flows for Role Authorization

➢ Checker clicks on “Inbox” on dashboard.

➢ A new screen will appear with a list of pending requests, double click on any pending
request for further processing.

10
 ➢ A side screen will open with the details requested by his inputter for approval, a
checker can review and clicks on Approve or Rejects and also input his comments.

2.2 User Management

2.2.1 User Creation/Modification

Ideally OC portal have following types of users.

A. Admin user/checker.
B. Operations / settlement user/checker.
C. Technical operation / support.

All users have different roles assigned to them to perform their daily tasks like fee management, limit
enhancement, roles for reconciliation, return payments, p2p payments, audit logging and viewing
reports.

11
2.2.2 Screen Flows for User Creation/Modification

➢ User with management rights login to portal and clicks on "User”.

+
➢ Users click on add button on top right corner “ ” to create a new user or double clicks on any
previously created user for modification.

When clicking on add button a new side screen appears, enter the required parameters like user ID,
Name, CNIC, Mob no, Email, Emp no, Dept, Designation, Remarks, Status and Role. Click on submit
button to move the request for authorization.

12
If you want to modify previously created ID then double on any ID and edit details or grant or revoke
rights, then pressing submit button to move the request to authorizer bucket.

2.2.3 User Authorization

✓ Checker login into OC portal.

✓ Checker clicks on “Inbox” from dashboard to check pending requests.
✓ List of pending requests appeared on checker screen.
✓ Checker click on request to view user details.
✓ Checker review user information and have following options:

o Approved o Reject

✓ Checker can select any of above option and input remarks.

✓ On approval user will be approved and newly created user can login into portal.
✓ On rejection user request will be return to maker with checker remarks.
✓ Maker can view return requests in a separate menu with checker comments.
✓ Maker can do the necessary changes and sent back request to checker for approval.
✓ Same process for checker will be followed on resubmission.

Newly created user will login with one-time password and system will enforced user to change
password on first login> Password regex is applied as per following security standard:

▪ Password must contain 1 alpha, 1 numeric, 1 capital, 1 small and 1 special character.
▪ Supporting characters are [0-9, a-z, A-Z,!@#$%^&*]
▪ Password minimum length is 8 and maximum length should be 20.
▪ Password must be different from last 5 passwords.
▪ User will be lockout on 3 invalid attempts.

13
2.2.4 Screen Flows for User Authorization

➢ User with checker rights login to the OC portal, and clicks on “Inbox”.

➢ A new screen will appear with a list of pending requests, double click on any pending
request for further processing.

14
➢ A side screen will open with the details requested by his inputter for approval, a
checker can review and clicks on Approve or Rejects and also input his comments.

15
3. Management Configuration

3.1 Daily Limit

There will be limit configured for all channels and transaction types to send payments. Limits should
be configured accordingly:
• An overall limit set for the Raast Payment on OC.
• There will be feature available to set limit for any specific channel and transaction type.
• Multiple limits profile id can be setup at a same time.
• Bank can also set limit for any specific institution on the basis of channel and transaction type.
• Limits will be checked on every single outgoing transaction.
• In any case if bank want to change limit for any specific customer, bank will add new profile
with and set attributes as per requirement.
• Bank can link that customer IBAN with that limit profile id. (Maker / Checker process).

3.1.1 Screen Flows for Limit Submission

➢ User with limit enhancement permission will login OC portal and clicks on “Daily Limit”.

16
 ➢ Now fill in required fields like channel, participant, limit per transaction, daily limit per day,
transaction frequency, limit set and financial transaction, then click on submit button to
move the request for authorization.

3.1.2 Screen Flows for Limit Authorization

➢ User with limit authorization rights will login to the OC portal and clicks on Management
Inbox.

17
➢ A list of pending requests will open.

➢ Double click on any pending request and after review click Reject or Approve and input
comments.

18
3.2 Transaction Fee Management
OC also have feature to setup fees. Fee can be setup in below manner:
• Fees can be defined for specific channel and transaction type
• Fee have following type:
o Fixed Fee
o Slab wise fixed Fee
o Percentage of the transaction amount
o Fixed fee and percentage whichever is higher
o Fixed fee and percentage whichever is lower
• For initial stage there will be no fee on transactions, but bank will be able to set fee at any
time.

3.2.1 Screen Flows for Fee Submission

➢ User having fee submission rights will login the portal and click on “Fee”.

19
 ➢ Fill in the required fields like channel, financial transaction, from amount, to amount, fee
type, fee value, fee applied and fee applied value, then click on submit button to move the
request to your authorizer.

3.2.2 Screen Flows for Fee Authorization

➢ User with fee authorization rights will login the OC portal and clicks on Management Inbox.

20
➢ A list of pending requests appears. Double click on any fee pending request and after review
click Reject or Approve and input comments.

21
4. Audit Logs
Users having transactions audit log viewing permission can navigate to their dashboard and click on
Audit Logs to view them.

Any transaction financial or non-financial are recorded in Audit Logs so that the end user can easily
track data against each transaction.

Ideally audit logs can reflect IP Address, Correlation ID, Activity Log, Channel, Request Date/Time, RRN,
Stan, Response Desc and Response Code.

The end user can also extract data using filters on Activities and channel respectively to goes through
any financial or non-financial transactions.

22
If a user wants to track any transaction in Audit Logs, simply double click on any transaction which
will navigate you to the Audit Log Details page, from there you can find details against each
transaction like inquiry, post-mx-message, debit-block, debit-confirm, debit-release, debit-hold,
credit request, incoming-payment and many others for different activities.

Not only this, in new Backoffice release we can also go through Host Request/Response without the
hectic of opening database every time to trace any transaction on system.

To trace any transaction’s request and response bodies for example if we want to trace
request/response against debit-block;

Double click on any transaction in Audit Log Details, a new side-screen will appear displaying ‘Host
Request’ and ‘Host Response’ for respective activity.

23
5. Return Payments

The Payment Return message is utilized to fix an installment recently settled. At the point when a
bank gets a pacs.008, it should handle it and books the amount to the recipient account. Be that as it
may, imagine a scenario where the recipient closes his account two days prior. Imagine a scenario
where the record doesn't exist at all in the Bank. In those cases, the bank cannot credit the record.

The recipient bank should return the cash to the originator Bank. Other than the reasons referenced
above, there are various reasons behind why a bank may need to return the cash. Regardless, it will
utilize the pacs.004 message to do that. The return has its own settlement date, the date at which
the amount will be paid back to the originator bank. The justification behind returning the funds is
demonstrated by a code in the return message.

A bank can only return the money that it has previously received. So, the payment return message is
initiated and sent after settlement.

The basic rule is that cash ought to be return as quickly as time permits to the originator.

5.1 Screen Flows for Return Payment Submission

➢ User with return payments permission login to OC portal and navigate to Return
Payments.

24
 +
➢ A screen will appear showing return payments details. Click on “ ” on left adjacent
to each transaction for which you want to submit return payment.

➢ Now a drop down list will appear, select rejection reason from that list and submit
request to checker for approval.

25
5.2 Screen Flows for Return Payment Authorization

➢ User with return payment authorization rights will login to the OC portal and
navigate to Payment Inbox.

➢ A new screen will appear listing details of return transactions initiated by maker.
Double click on any transaction, review thoroughly and then click on approve/reject
and input comments.

26
6. SAF Details

In new back office we have include a SAF functionality, by which you can control any stuck
transaction in SAF of inward or outward payment which cannot be processed due to any
reason and stuck in SAF. SAF mechanism is designed like that if any transaction got rejected
3 times from endpoint, then that particular transaction would be parked in SAF. Then user
have to retransmit or either mark it as expired if they manually handling debit or credit.
If user have SAF details rights in his ID then go to Dashboard and click on SAF Details.

A new screen will open by clicking on SAF Details button, there you can see Three different
type of Transactions.
1- Credit
2- Debit-Confirm
3- Debit-Release

If you want to check transactions just double click on any of the transaction type and just
below particular transactions will be appeared.
In Credit, incoming transactions will appear that were rejected by CBS ‘3’ time due to any
reason and stuck in SAF.
In Debit Confirm, those transaction will appear in which we had received failure from CBS
on debit confirmation request.

27
In Debit Release, only those transaction will appear that were rejected by CBS system while
sending reversal to CBS in case when we receive failure from counter party.
Those banks that control debit manually (Direct Posting) will only have to SAF Details
functionality to handle incoming transactions.

If you want retransmit transaction again for CBS processing then click on Refresh button and
the transaction will be submitted directly to CBS for processing. Or you can also mark that
transaction as Expired by clicking on Expiry button.

28