Solution Document API Based ERP Integration - Postlogin Onboarding Journey v0.9 - 05062021

State Bank of India
Project Name-Yono Business –API Banking
Solution Document
for
API Banking Onboarding (Post-login) through yonoBusiness
Version No.: 0.9
Module Name: yono_Business_API Banking
Tech Mahindra
Solution Document_API Banking Onboarding through yonoBusiness Page 1 of 60

Project Confidential
Impacted Stakeholders
# Name Role Organisation Shared On
1 Mr. Venkatavelu P.S. DGM State Bank of India
2 Ms. Jaya Pai DGM State Bank of India
3 Pandiarajan A AGM State Bank of India
4 Prasoon Kumar Chief Manager State Bank of India
5 Ashish Mishra Manager State Bank of India
6 Devesh Verma Manager State Bank of India
7 Hemangini Rakesh Fotedar Project Manager Tech Mahindra
8 Guruprasad Rao Project Manager Tech Mahindra
9 Manish Madhukar Kokate Technical Architect Tech Mahindra
10 Vaibhav Banavalikar Technical Architect Tech Mahindra
Sign- Off History
Sign-off Person Name Date Signature
SBI-Business/CCG YB- Mr. Venkatavelu P. S.
Analytics
SBI-Business/CCG YB- Mr. Lovesh Abichandani

Analytics
SBI-Business/CCG YB- Mr. Devesh Verma
Analytics
SBI-IT/SBI GITC-INB Ms. Jaya Pai
SBI-IT/SBI GITC-INB Mr. Pandiarajan A
SBI-IT/SBI GITC-INB Mr. Ashish Mishra

Version History
Version No Date Author Changes Made

0.1 30-May-2020 Nilesh Londhe  Initial Draft
 Incorporated review comments
0.2 05-June-2020 Nilesh Londhe
 Added user story for GITC Approval
 Added additional business validations for
Debit account selection in Onboarding
User stories
0.3 19-June-2020 Nilesh Londhe  Updated YBBI Approval User story for
new workflow (GITC Approval added)
 Added the GITC approval process for the
Onboarding journey.
 Added validation for RBI Advisory 4,
0.4 21-July-2020 Nilesh Londhe
updated user story US07_Branch Maker
0.5 13-Aug-2020 Nilesh Londhe  Incorporated Business review comments
 Added option to select a Transaction user
while onboarding, Updated user story
0.6 20-Aug-2020 Nilesh Londhe
US03_Postlogin_Onboarding to API
Banking
 Updated onboarding user story for new
approach for CINB integration
0.7 22-Apr-2021 Nilesh Londhe  Merged Aggregator solution document
with post login onboarding solution
document
 Incorporated review comments
0.8 25-May-2021 Nilesh Londhe
 O-Auth parameters updated
 Added PAN validations under O-Auth
0.9 02-June-2021 Nilesh Londhe
Parameter

Table of Contents
1. DESCRIPTION.........................................................................................................................................................7
2. SCOPE........................................................................................................................................................................7
3. OUT OF SCOPE.......................................................................................................................................................7
4. EXISTING FUNCTIONALITY..............................................................................................................................7
5. FUNCTIONAL SPECIFICATION/PROPOSED SOLUTION............................................................................8
5.1 YONO BUSINESS ONBOARDING PROCESS.........................................................................................................8

5.1.1 Aggregator Onboarding.................................................................................................................................8
5.1.2 Post login onboarding in yono business........................................................................................................9
5.1.3 Branch Approval for onboarding using YBBI................................................................................................9
5.1.4 GITC Approval for onboarding (Technical Approval)................................................................................10
5.1.5 Payment Initiation process (in Aggregator model)......................................................................................10
6. TECHNICAL/OTHER SPECIFICATIONS........................................................................................................11
6.1 PRE-REQUISITES AT ERP SYSTEM.....................................................................................................................11

6.2 AGGREGATOR TABLE STRUCTURE AND SCRIPTS..............................................................................................11
6.3 STEPS FOR GETTING SFG ACCESS....................................................................................................................12
7. USER STORIES......................................................................................................................................................13
7.1 POST LOGIN ONBOARDING USER STORIES....................................................................................................13

7.1.1 US01_Aggregator Onboarding....................................................................................................................14
7.1.2 US02_Postlogin_API Banking Tab View.....................................................................................................15
7.1.3 US03_Postlogin Regulator Action for Vistaar Corporates.........................................................................16
7.1.4 US04_Postlogin_Onboarding to API Banking............................................................................................17
7.1.5 US05_Postlogin_Update Existing Information...........................................................................................25
7.1.6 US06_Postlogin_Check Application Status.................................................................................................28
Solution Document – Yono_Business_API-based ERP Integration Post Login Onboarding
Page 4 of 60
7.1.7 US07_Postlogin UAT Completion...............................................................................................................30
7.1.8 US08_Token Management...........................................................................................................................32
7.2 YBBI USER STORIES.......................................................................................................................................34
7.2.1 US07_Branch Maker Action........................................................................................................................34
7.2.2 US08_Branch Checker Action.....................................................................................................................36
7.3 YBBI GITC USER STORIES............................................................................................................................38
7.3.1 US09_GITC Approval for Onboarding Request..........................................................................................38
7.3.2 US10_GITC Approval for UAT Completion................................................................................................41
7.3.3 US11_GITC Approval for Modification Request.........................................................................................43
7.4 TRANSACTION INITIATION IN AGGREGATOR MODEL...................................................................................47
7.4.1 US12_Payment Initiation in Aggregator Model..........................................................................................47
8. INTERFACES / SERVICE CALLS......................................................................................................................49
8.1 CORPORATE VALIDATION SERVICE...............................................................................................................49

8.2 CORPORATE DETAILS SERVICE......................................................................................................................49
8.3 TOKEN GENERATION SERVICE........................................................................................................................50
8.4 TOKEN REVOCATION SERVICE........................................................................................................................50
9. ASSUMPTIONS AND DEPENDENCIES............................................................................................................51
10. RISKS..................................................................................................................................................................52
11. SUPPORTING DOCUMENTS.........................................................................................................................53
12. ABBREVIATIONS.............................................................................................................................................54

Page 5 of 60
Table of Figures
Figure 1: Steps in API based ERP Integration..................................................................................................8
Figure 2:Post login Onboarding.....................................................................................................................13
Figure 3:UAT Completion.............................................................................................................................30
Figure 4:Branch Maker Action.......................................................................................................................34
Figure 5:Branch Checker Action....................................................................................................................36
Figure 6:GITC Approval for Onboarding Request.........................................................................................39
Figure 7:GITC Approval for UAT Completion..............................................................................................41
Figure 8: GITC Approval for Modification Request......................................................................................44

Page 6 of 60
1. Description
SBI Corporate currently offers few API services through the CINB and CMP platforms. SBI plans to explore
and further extend these services through a host of standard and customized set of offerings as part of
the ERP integration. API interfaces enable corporate to integrate financial functionality like payment
initiation, balance enquires offered by SBI into their existing business application. And that too with no
major changes or disruption to routine business function. SBI will be using the IBM developer portal for
API registration and subscription.
2. Scope
This document covers below-mentioned journeys of API Based ERP Integration
 Aggregator onboarding (offline process)
 Post-login online onboarding process through yono business with Aggregator option
 Token Managment in yono business (required for Aggregator model)
 Online Branch Approval using YBBI
 GITC approval using YBBI Portal
 Transaction initiation in Aggregator ERP system using SBI’s APIs
 Customer segment considered is CUG Corporates for Pilot, later all customers will be considered
 Transaction initiation through API and Processing in CINB including authorization in case NON STP
is selected
3. Out of Scope
This section comprises the modules or functionalities that are not in scope from the delivery perspective
in the current release. These requirements are to be considered in subsequent phases of ERP journey
 Other Customer segments: E-commerce players, Payment Gateways, Urban Cooperative Banks
(UCBs), Scheduled Commercial Banks (SCBs)
 Any other items not listed explicitly under In Scope
4. Existing Functionality
N/A
Page 7 of 60
Page 8 of 60
5. Functional Specification/Proposed Solution
The ERP integration with SBI’s API Banking system will happen through developer portal-based registration
and API subscription. As a prerequisite, Corporate need to submit certain details required for enabling ERP
integration with SBI’s API Banking systems, Corporate will have to submit these details using yono business.
Once Corporate completes the onboarding process in yono business, post-approval by branch, Developer
portal will be enabled for the Corporates for registration and subscription for API.
Below are the prerequisite steps for API Banking.
Figure 1: Steps in API based ERP Integration
5.1 Yono Business Onboarding process

The onboarding process in yono business is mandatory for UAT and Production environment access,
however, the Sandbox environment can be accessed without completing the onboarding process in yono
business.
Corporate’s information including email id and mobile number of the technical team, debit accounts for
ERP based payments, Transaction limits, Authorization parameters (Corp id, PAN no, TIN No, TAN, GST No,
Client Id of corporate) for generating authorization token and technical information of ERP system
including IP, Port along with security certificate is captured during onboarding process in yono business.
Corporate’s who does not have an on premises ERP systems can also use API banking services by using
Aggregator based ERP integration model. In this model, Corporate can use ERP service provider
(Aggregator) for API integration with SBI. For “Aggregator based ERP integration”, corporate is required to
select the Aggregator and specify only transactional details.
Corporate will be categorized as CINB or CMP corporate basis Corporate ID provided while onboarding to
API Banking. In case Corporate has subscribed to both CINB and CMP, API based transaction processing will
happen as per primary product (CINB/CMP whichever is subscribed earlier) mapping with the corporate.
Yono business allows corporate onboarding for API banking in both Pre-login and Post-login journey.

Page 9 of 60
5.1.1 Aggregator Onboarding
For Aggregator based ERP Integration, as a prerequisite Aggregator is required to be onboarded into the
system. Aggregator onboarding will be done in offline mode and will not have any screens in yono business.
For details, refer7.1.1 US01_Aggregator Onboarding user story.
5.1.2 Post login onboarding in yono business

Corporates who are the existing digital customer (yono) can complete the onboarding process by login to
the yono business and submitting transactional and integration details in yono business API Banking
onboarding form.
Corporates opting for Aggregator based ERP Integration are required to submit only transactional details
while doing onboarding in yono business and all technical information including IP, Port along with security
certificate of the selected ERP provider should be considered.
For Aggregator model, post onboarding application is approved by bank, Corporates are also required to
generate unique token in yono business as a precondition for API usage.
For details, refer7.1 Post Login Onboarding User Stories, following list of User stories
 US02_Postlogin_API Banking Tab View
 US03_Postlogin Regulator Action
 US04_Postlogin_Onboarding to API Banking
 US05_Postlogin_Update Existing Information
 US06_Postlogin_Check Application Status
 US07_Postlogin UAT Completion
 US08_Token Management (applicable for aggregator model only)
5.1.3 Branch Approval for onboarding using YBBI

For API Banking Onboarding request, approval from Branch is required. Branch approval is also required in
case Corporate modify transactional details (Debit Account, Transaction User, API Catalog) later.
YBBI will be used for API Banking onboarding approval at respective branch and GITC (for technical
approvals).
For CMP Corporates approval will happen in CMP OC HYD Branch and for rest of the Corporates,
onboarding approval will be done in Corporate’s home branch.
Page 10 of 60
For details, refer7.2 YBBI User Stories, following list of User stories
 US07_Branch Maker Action
 US08_Branch Checker Action

Page 11 of 60
5.1.4 GITC Approval for onboarding (Technical Approval)
Once the API Banking Onboarding request is approved by Branch, the next stage is GITC approval for
technical details. GITC User will also approve UAT completion request and any change in technical detail for
existing API banking application
For details, refer7.3 YBBI GITC User Stories, following list of User stories
 US09_GITC Approval for Onboarding Request
 US10_GITC Approval for UAT Completion
 US11_GITC Approval for Modification Request
5.1.5 Payment Initiation process (in Aggregator model)

Post successful onboarding and integration using Aggregator based ERP corporate can initiate a payment
transaction using SBI’s APIs.
Please refer below user story for sample case explaining how transaction will be processed when initiated
in using a ERP provider (for Aggregator model)
7.4 Transaction initiation in Aggregator Model

Page 12 of 60
6. Technical/Other Specifications
6.1 Pre-requisites at ERP system
For initiating any request through API, corporates ERP system need to have below listed
prerequisites available.
1. Generate dynamic AES 256 bit key
2. Encrypt payload using AES256 algorithm
3. Add dynamic key to the payload
4. Encrypt dynamic key using RSA public key of YONOB
5. Add client id and secret key to the header for authentication
6. Digitally sign the payload using a private key
6.2 Aggregator Table Structure and Scripts

Please refer to below table structure for maintaining Aggregator details in the yono business system.
SBI_YB_APIBNKNG_AGGRTR_MSTR
Parent Table NA
Foreign/Reference Key NA
Column Name Type Mandatory Constraint Description
AGGRTR _ID VARCHAR (10) Y Primary Id creation logic is
key same as corporate id
AGGRTR_NAME VARCHAR (100) Y
AGGRTR _EMAIL VARCHAR (30) N
TECH_DEPT_EMAIL VARCHAR (30) Y Id will be used for

developer portal
registration
AGGRTR_DTLS VARCHAR (30) N
ACTIVE CHAR Y
INSERT_TS TIMESTAMP Y
UPDATE_TS TIMESTAMP N
UPDATE_BY TIMESTAMP N
UPDATE_COMMENTS VARCHAR (100) N Its mandatory in

case of any changes

Page 13 of 60
to the record.
Table creation script
CREATE TABLE "UATAPIBNKNG"."SBI_YB_APIBNKNG_AGGRTR_MSTR"
( "AGGRTR_ID" VARCHAR2(10 BYTE),
"AGGRTR_NAME" VARCHAR2(100 BYTE),
"AGGRTR_EMAIL" VARCHAR2(30 BYTE),
"TECH_DEPT_EMAIL" VARCHAR2(30 BYTE),
"AGGRTR_DTLS" VARCHAR2(30 BYTE),
"ACTIVE" CHAR (1 BYTE),
"INSERT_TS" DATE DEFAULT SYSDATE,
"UPDATE_TS" DATE,
"UPDATE_BY" VARCHAR2(30 BYTE),
"UPDATE_COMMENTS" VARCHAR2(100 BYTE)
) SEGMENT CREATION IMMEDIATE
PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255
NOCOMPRESS LOGGING
STORAGE (INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1
BUFFER_POOL DEFAULT FLASH_CACHE DEFAULT CELL_FLASH_CACHE DEFAULT)
Insert Script
Insert into SBI_YB_APIBNKNG_AGGRTR_MSTR
(AGGRTR_ID,AGGRTR_NAME,AGGRTR_EMAIL,TECH_DEPT_EMAIL,AGGRTR_DTLS,ACTIVE,INSERT_TS,UPDAT
E_TS,UPDATE_BY,UPDATE_COMMENTS) values ('1234','ABC
LTD',’xyz@abc.com’,'techitdept@abc.com',’Aggregator corporation for payment’,'Y',current
timestamp,null,null,null);
6.3 Steps for getting SFG Access

For getting SFG access following steps are required
1. Corporates are required to submit application for SFG access with bank,
2. On approval, a link (web URL) will be shared with Corporate
3. Corporate is required to create user name using the shared link
4. On successful user creation, dedicated folder with corporate name will be created on SFG
location

Page 14 of 60
5. Corporate should use the folder for sharing required documents

Page 15 of 60
7. User Stories
7.1 Post Login Onboarding User Stories
Figure 2:Post login Onboarding

Page 16 of 60
7.1.1 US01_Aggregator Onboarding
User Story US01_Aggregator Onboarding (offline onboarding process)
As an aggregator, I want to register as an ERP service provider for SBI’s API Banking services. So that using ERP
integration services provided, SBI’s corporate customer can use API banking offered by SBI
Type Master setup /Data setup Priority High

Prerequisite Aggregator has completed sandbox environment integration
Process Flow Aggregator onboarding
Step1: Aggregator apply for onboarding to API Banking as an ERP service provider
Following details should be provided by the Aggregator
A. Technical Teams email id (This email id cannot be changed in future)
B. O-Auth Parameters (PAN, TIN, TAN, Corporate ID, GSTIN, Corporate CIN)
C. Password (password using password rules like yono business -8-20
characters, at least 1 special character, at least 1 number, at least 1
alphabet)
D. IP address, Digital Certificate, Security Certificate for UAT environment (SFG
should be provided for sharing these details)
E. Signed copy of NDA (with Validity of 1 year) and another legal documents
submission
Step 2: Bank’s team approves the aggregator onboarding application and assigns a
validity period and renewal date of minimum 1 year according to validity
of NDA and agreement
On approval on Aggregator onboarding,
A. Aggregator details should be pushed to DB (using scripts 6.2 Aggregator
Table Structure and Scripts )
B. Unique Aggregator ID will be created
C. IP whitelisting for should be done for IP details shared in application form
D. Developer portal admin should send a unique registration link for UAT
environment to the aggregator email ID, validity for the invite email should
be configured according to security practices of bank (1 day)
E. Aggregator ID should be shared with the aggregator (through email by bank’s
team)
Step 3: Aggregator completes the UAT registration using the unique registration
link
On completing registration on UAT portal
A. Aggregator should test the APIs in UAT environment
B. Aggregator should submit the UAT exit report along with Production
environment details.
C. Following details should be shared for Production environment
IP address, Digital Certificate, Security Certificate
Page 17 of 60
D. UAT exit report and server certificates should be shared using SFG
Step 4: Bank’s team reviews UAT completion details shared by Aggregator
A. On approval of UAT completion, Aggregator should get invite link for
Production
B. On rejection of UAT completion, email should be sent to Aggregator on the
email address mentioned while onboarding
Step 5: Aggregator completes the Production environment registration using the
unique registration link
On completing registration on Production environment
A. Aggregator should be allowed to integrate APIs in Production environment
B. Aggregator details should be available for selection in yono business post
login onboarding when corporate selects “Aggregator based ERP”
Acceptance Please refer below table for validations
Criteria
Scenario Expected Result
Aggregator has completed UAT, however Aggregator details should not be available
UAT approval is pending for selection in yono business post login
Aggregator has not shared any of the UAT invite link should not be sent to
mandatory details required for UAT access Aggregator
Aggregator validity is expired, and System should not allow to select the
renewal not done aggregator in yono business post login
onboarding
Aggregator has production environment System should allow to select the
access aggregator in yono business post login
onboarding
Notes A. Aggregator details like Email ID, PAN, TIN, TAN, GSTIN, Server IP should be shared
using application form (offline onboarding form)
B. Secure File Gateway should be provided for sharing Digital Certificate, Security
Certificate, Hashed Password
C. UAT exit report should be shared over using SFG
D. Aggregator should have a validity and next renewal date (should be captured while
onboarding)
Reference 5.1.1 Aggregator Onboarding
7.1.2 US02_Postlogin_API Banking Tab View

User Story US02_YONOB_Postlogin_API Banking Tab View

Page 18 of 60
As a corporate user who wants to get access to the API banking platform, I should be able to view API banking
tab such that I would be able to see details & raise the API banking access request
Type Master setup /Data setup Priority High Effort Estimate High
Process Flow Post login Tab View
Step1: Corporate User login to yono business
Step2: Corporate User selects API Banking menu
Step 3: Corporate User selects Onboard Now on API Banking page
System to do following validations for logged in Corporate user
Acceptance Please refer below table for validations performed for logged in Corporate user as per
category
Criteria

Regulator user for Vistaar corporate login API Banking page should be displayed
to yono and selects API Banking
Admin user for Vistaar corporate login to API Banking page should be displayed
yono and selects API Banking
Any other user (maker, checker, file Error message “you do not have privileges
uploader) for Vistaar corporate login to to access this page” should be displayed
yono and selects API Banking
Khata, KhataPlus, Saral corporate login to API Banking page should be displayed
yono and select API Banking
Regulator user selects onboard now A message should be displayed as “As a
Regulator you need to nominate an
Admin user for API Banking “
Admin user not nominated by Regulator A message should be displayed as “Please
selects onboard now get rights from Regulator for API Banking”
Admin user nominated by Regulator Onboarding page should be displayed
selects onboard now
Khata, KhataPlus, Saral corporate user Onboarding page should be displayed
select onboard now
Notes
Reference
7.1.3 US03_Postlogin Regulator Action for Vistaar Corporates

User Story US03_YONOB_Postlogin Regulator Action for Vistaar Corporates

Page 19 of 60
As a Regulator, I should be able to select Admins who can complete onboarding request for API banking post
login to yono business
Process Flow Admin user selection
Step1: Regulator login to yono business
Step2: Regulator selects API Banking menu
API Banking landing page should be displayed
Step 3: Regulator user selects Onboard Now on API Banking page
“As a Regulator, you need to choose an Admin for API Banking Onboarding”
message should be displayed to Regulator along with a popup screen to select
Admin user
Step 4: Regulator user selects a Primary Admin from List of all Admin users
The system should allow Regulator to select Primary Admin and should display a
message “Do you want to select a secondary admin” with “Yes” and “No” options,
I. On selecting Yes, the system should display a list of Admin users and allow
the Regulator to select Secondary Admin.
II. If Regulator user selects No, Admin user list for selection of secondary admin
should not be displayed
Step 5: The regulator user selects a Secondary Admin from a List of Admin users.
The system should allow to select Secondary Admin and should give confirmation
message.
Step 6: Regulator user does not select secondary admin and continues to proceed
System should allow Regulator to submit details without selecting Secondary
Admin
Step 7: Process End
Acceptance Please refer below table for validations performed for the logged-in user as per category
Criteria
Regulator user for Vistaar corporate login API Banking page should be displayed
to yono and selects API Banking
Regulator user clicks on Onboard Now The system should display a message “As
button on API Banking page a Regulator, you need to select an
Administrator for API Banking Onboarding
“and should display a list of Admin users
for selection
Regulator user selects a Primary Admin The system should display a message” Do
and proceed you want to select a Secondary

Page 20 of 60
Administrator “with Yes and No options
Regulator user selects Yes for selecting The system should display a list of Admin
secondary Admin user and allow the Regulator to select
Secondary Admin
Regulator user selects No for selecting Admin user list for selection of secondary
secondary Admin admin should not be displayed
Regulator user selects a Secondary Admin The system should allow to select
from List of Admin users Secondary Admin and should display a
confirmation message
Regulator user does not select any Admin The system should show API banking
user and clicks on Cancel landing page
Notes
Reference
7.1.4 US04_Postlogin_Onboarding to API Banking

User Story US04_Onboarding to API Banking Post Login
As a Corporate Admin User, I should be able to complete the onboarding process for API Banking by
submitting the required details post login to yono business
Pre requisite Aggregator is successfully onboarded and available for selection
Process Flow Onboarding
Step1: Corporate Admin user login to yono business and select API Banking
menu
System to display API Banking landing page with below options
Onboard Now /Update Existing Application/ Check Status /UAT Completion/
Token Generation.
Step2: Admin User selects Onboard Now
1. System to check if Corporate already onboarded for API.
2. If found duplicate request, an error message “Your company has already
registered for API banking, please check the status for more details
“should be displayed
3. If not duplicate, System should allow Admin User to continue the

Page 21 of 60
onboarding process
Step3: System checks Customer type for the logged-in Corporate Admin User
1. If customer type is in Vyapaar, Saral, Khata, Khata-Plus
2. The system should redirect Admin User to onboarding details screen
3. If customer type is Vistar
4. System to check User type (Regulator or Admin)
Step4: User type is Regulator
The system should display a message; “Regulator need to select admin user for
Onboarding to API”
Step5: User type is Admin
System to check rights for API Banking onboarding
Step6: If Admin user does not have rights to onboard for API
1. The system should display a message “Please contact the regulator for
API banking onboarding privileges “
2. If admin user has rights for onboarding to API banking
3. Onboarding details page should be displayed
Step7: Admin User check the onboarding details page
Following tabs should be available
1. Onboarding Details
2. Transaction Details
3. Integration Details
4. Preview and Submit
Step8: Onboarding Details
Following details are to be entered/selected in Onboarding details tab
ERP Type Selection, API Selection, Authorization Mode selection (STP/
NON STP) and Other Onboarding Parameters
1. User to select ERP Type
Corporate User should be displayed 2 options for selection
A. On Premises ERP
B. Aggregator based ERP
1.1 User selects “On Premises ERP”
A. System should allow user to select On Premises ERP
B. System should allow user to continue onboarding for API banking
and should allow user to enter integration details like Server IP,
Server certificates
1.2 User selects “ERP Provider (Aggregator)”
A. System should display a list of all active Aggregators.
B. Aggregator ICON with Radio Button will be displayed for user
Page 22 of 60
selection.
C. System should allow User to select Aggregator using the radio
button for selection
D. System should display a text box to enter Corporate’s ID
(Corporate identifier) for validation with Aggregator
E. System should also display a Validate button (for validating that
corporate is a customer of the selected aggregator)
1.3 User selects Aggregator, enters Corporate ID and Validate
A. System should send Corporate ID to the selected Aggregator,
using service request API hosted at aggregator end (Ref 8.1
Corporate Validation service:)
B. For negative response received from the Aggregator, system
should display error message “Invalid Details” and onboarding
journey should end
C. In case of technical errors (network issue, response time out),
system should display error message as “Technical error, please
retry”
D. For success response from the Aggregator, system should allow
user to continue with onboarding journey
E. In Integration details tab, system should display server and ip
detail of the selected Aggregator in read-only mode (for printing
in omnibus document)
2. User to select O-Auth parameters
A. User will be displayed list of following O-auth parameters for
selection
1) Corporate PAN,
2) Corporate TIN,
3) Corporate TAN,
4) Corporate GSTN,
5) Corporate ID,
6) Corporate CIN
B. User will be required to select minimum 4 out of the 6
parameters and user is expected to enter value for the selected
parameter
C. System should not allow to proceed further without selecting and
entering value for minimum 4 parameters
D. Structure validations should be done on the entered value
i. PAN
 Length must be 10
 4th Character should not be” P” for Corporates

Page 23 of 60
ii. TIN
 Length must be 10
 First 4 characters should be letters, followed by
5 Numerical values and last character should be
letter
3. User to select APIs

3.1 Corporate has selected ERP type as “On Premises”
i. System should display all available APIs categorized in different
catalogs/ groups (like Payment APIs, Collection APIs, Trade APIs)
ii. System should allow user to select APIs from available catalog
3.2 Corporate has selected ERP type as “ERP Provider (Aggregator)”
A. System should display all available APIs categorized in different
catalogs/ groups (like Payment APIs, Collection APIs, Trade APIs)
B. System should display APIs available with the selected
Aggregator only
C. System should allow user to select from available API catalog
4. User to select Authorization type
A. System should display authorization type as STP or NON STP at
API catalog level for selection.
B. System should allow to select authorization type at product
/catalog level
C. Selected authorization type (STP/NON STP) should be applicable
only for transactional APIs from the selected catalog and all non-
value/ non transactional APIs will be NON STP (without
authorization) by default
D. System should allow user to change previously selected
authorization type (toggle between STP/NON STP)
4.1 User select Authorization Type as “STP” for an API Catalog
A. All transactions created using an API from the selected catalog
should be processed in STP mode and authorization will not be
required
B. API banking transaction limit will be considered only for STP
mode of transaction processing which is 50 lakhs currently
4.2 User select Authorization Type as “NON STP” for an API Catalog
A. Only value based / transactional APIs from the selected catalog
will need authorization
B. All non-value / enquiry APIs from the selected catalog will not
need any authorization (irrespective of NON STP selection at

Page 24 of 60
Catalog level)
C. For NON STP transactions existing authorization rules defined in
CINB/CMP will be applicable
D. System will not process transactions with NON STP mode if
authorization rules are not available in CINB/CMP
E. Existing account level limit configured in CINB/CMP will be
considered for NON STP mode of transaction processing.
4.3 User changes previously selected authorization type
A. System should allow to change Authorization type by using Edit
Application Option (Ref 7.1.5 US05_Postlogin_Update Existing
Information)
B. Any change in authorization type will be applicable for new
transactions only and all existing/ InProgress transaction will be
processed as per already selected rule
C. New authorization rule should be effective after request is
authorized by bank
5. User enters other parameters
Following details are to be entered/selected in Onboarding details
A. Technical Team Email id, Technical Team Mobile no, Corporate Email
Id (applicable only for Corporates having On Premise ERP systems)
B. O-auth parameters (PAN, TIN, TAN, Corporate ID, GSTIN, Corporate
CIN))
Step9: Transaction details
Following details are to be entered /selected in the Transaction details tab
i. Transaction User details to be submitted. (Below options to be display
while adding each transaction user)
A. Name, Mobile No, CINB/CMP Role
B. System should not have any restriction in adding transaction
users
C. Mobile Number mentioned here should be validated for OTP
Service.
D. OTP request coming for mobile numbers other than specified in
API Banking onboarding should be rejected
ii. Debit Account Details
A. All debit accounts of the Corporate should be considered for
API banking and separate selection should not be required at
the time of onboarding to API banking
B. Omnibus document and Terms & Conditions should be modified
to add all debit accounts of the Corporate for API Banking.
iii. Transaction Limit to be entered
A. System should display Limit allowed by the Bank basis
Page 25 of 60
Corporate type in read-only mode
B. System should allow corporate to specify limit, in case
corporate does not specify its limit, bank limit should be
considered as corporate limit
C. API banking transaction limit will be considered only for STP
mode of transaction processing which is 50 lakhs currently
D. Existing account level limit configured in CINB/CMP will be
considered for NON STP mode of transaction processing.
Step10: Integration details

1. For ERP type as “ERP Provider (Aggregator)”
In Integration details tab, system should display server and ip detail of the
selected Aggregator in read-only mode (for printing in omnibus document)
2. For ERP type as “On Premises ERP”
Following technical integration details are required to be submitted
A. Details for ERP service provider and Version
B. IP Details and Digital Certificate for UAT environment
This is mandatory information
C. IP Details and Digital Certificate for the Production environment.
(Production environment details are non-mandatory while doing
onboarding)
Step11: Admin User enter all required information and select Proceed
Preview page displayed with Terms & Condition checkbox
Step12: Admin User clicks on Terms & Condition
System to display Terms & Conditions in a pop-up window
Step13: Admin User checks Terms & Condition and Submit
A. System to check for all mandatory fields and if any of the mandatory
fields is not entered, display an appropriate error message
B. If all mandatory details are available, should allow Admin User to submit
the application and to display a new screen with following
i. The system generates Ref No and displays on the screen
ii. A message should be displayed “Please approach home branch
(Branch Name) for further processing”
Branch Name should be derived basis logged in Corporate Admin
iii. The omnibus document should be generated with all information
entered in onboarding and should be available for download, print,
and share over email
iv. In case user enter an email id other than the registered email of the

Page 26 of 60
corporate, system to send a copy to the registered email id
Step14: End Process
Acceptance Please refer below table for validations performed for onboarding in post login journey
Criteria
Regulator user selects onboarding now The system should display an error
an option on API banking landing page message “As a regulator, please
nominate Admin user for API Banking
onboarding”
Admin user for existing API banking The system should display an error
customer selects Onboard Now message “Your company has already
registered for API banking, please check
the status for more details”
In the Onboarding details tab, the user The system should give an error message
does not specify all mandatory details “Please enter all mandatory details in all
and moves to the next tab tabs “
Khata /Khataplus user checks available For Khata/Khataplus users only Enquiry
API’s API’s (Balance Enquiry API) should be
available
SARAL/Vyapaar /Vistar user checks For SARAL/Vyapaar/Vistar corporate
available API’s both Transaction and Enquiry API’s
should be available
In Onboarding details tab user selects System should display one more option
Beneficiary Management API’s for selection “Validate Beneficiary at the
time of Transaction “with a checkbox for
selection
The user selects “Validate Beneficiary at The system should allow the user to
the time of Transaction “as Yes select and should validate beneficiary
details at the time of transactions
The user selects “Validate Beneficiary at System should allow the user to select
the time of Transaction “as No and should not validate beneficiary
In the Transaction Details tab, Admin System should not allow and should
User try to enter Corporate Limit more give error message as “Corporate
than Bank defined limit Limit cannot be greater than Limit
allowed by Bank”
Note: Actual value for Limit allowed by
Bank should be displayed basis logged in
Corporate’s customer type
In the Transaction Details tab, Admin The system should give an error message
Page 27 of 60
User does not specify all mandatory “Please enter all mandatory details in all
details and moves to the next tab tabs “
In the Integration details tab, Admin User The system should not allow and should
does not upload a valid certificate give an error message, invalid certificate
(security certificate upload in txt, jpeg
format)
In the Integration details tab, Admin User The system should give an error message
does not specify all mandatory details “Please enter all mandatory details in all
and moves to next tab tabs “
In the preview page, Admin User clicks on System should redirect the user to the
back button Onboarding details tab and should allow
the user to update details in all tabs
In preview page, Admin User clicks on System should open a popup window
Terms & Condition link with Terms & Condition details
Admin User submit details without System should not allow the user to
selecting Terms & Conditions submit the details and should display an
error message as “Please select Terms &
Conditions”
Admin User enters all mandatory fields, 1. System should allow submitting details
selects Terms & Conditions and submit and should generate an onboarding
the onboarding request reference number
2. System should also generate an
omnibus document with options to
download/print /email
3. System should display a message
“Please visit your home branch for
approval”
Corporate user enters email id other than In case user enter an email id other than
registered email ID for sending the the registered email of the corporate,
omnibus document by email system to send a copy to the registered
email id along with the email id
mentioned
Admin User download Omnibus System should allow to download

document Omnibus document
In Transaction User details, Admin System should display list of all existing
chooses to Select Existing User users for the corporate and should allow
Information Admin to select a user
In Transaction User details, Admin System should allow Admin to specify
chooses to Enter New User Information below details for the transaction user
1. Name

Page 28 of 60
2. Mobile Number
3. Email Address
4. PAN
User selects ERP type as “ERP System should allow and should display
Provider (Aggregator)” list of available ERP service providers and
should display Validate button
User selects a service provider from the System should display an error message
list, does not enter Corporate ID as “Please enter Corporate ID for
registered with the selected Aggregator Validation”
and Validate
User does not select Aggregator from the System should display an error message
list and Validate as “Please select Aggregator from the
list”
User select Aggregator Name, enters System should send details to the
Corporate ID (registered with selected selected Aggregator using API hosted
Aggregator) and validate at the Aggregator (Ref 8.1 Corporate
Validation service for service level
details)
Negative response received from the System should display error message as
Aggregator for Corporate validation “Invalid details” and should not allow
user to continue onboarding
Technical error received from the System should display error message as
Aggregator for Corporate validation “Technical error, please retry” and should
not allow user to continue onboarding
User exceeds maximum retry attempts System should display error message as
(3) and success response not received “Validation cannot be completed, please
from aggregator check with the selected ERP provider”
and should not allow user to continue
with onboarding process
Success response received from the System should display message as
Aggregator “Validation completed successfully” and
should allow user to continue onboarding
Note 1. Aggregator details (Aggregator Name, Aggregator Validity, Production server
details) should be part of Omnibus document
2. Corporate will be categorized as CINB or CMP corporate basis Corporate ID
provided while onboarding to API Banking.
3. In case Corporate has subscribed to both CINB and CMP, API based transaction
processing will happen as per primary product (CINB/CMP whichever is
subscribed earlier) mapping with the corporate.
Reference
Page 29 of 60
7.1.5 US05_Postlogin_Update Existing Information
User Story US05_Update Existing Information in Post Login Journey
As a Corporate Admin, I should be able to update existing information for API Banking for my organization
post login to yono business
Process Flow Update Information
Step1: Corporate Admin login to yono business and select API Banking menu
Onboard Now /Update Existing Application/ Check Status /UAT Completion.
Step2: Admin User selects Update Existing Application
The system should display the Onboarding details tab and should allow Admin
User to update applicable values
Step3: Admin User edits Onboarding details
i. The system should not allow changing Technical team’s email address
ii. The system should allow to update the Technical team’s mobile number
and update API selection
Step4: Admin User edits Transaction details
Following details can be edited in the Transaction details tab
i. Transaction user details
Transaction Users can be disabled (soft delete) or Updated
ii. Debit Account Details
iii. Transaction Limit (Corporate limit)
Changes in transaction details will need updated BR and Omnibus document and
Branch approval
Step5: Admin User edits Integration details
Following technical integration details can be updated
i. IP & Port Details and Digital Certificate for UAT environment
ii. IP & Port Details and Digital Certificate for the Production environment
Change only in Integration details will require GITC Approval Branch approval and
Omnibus document is not required
Step6: Admin User enter all required information and select Proceed
Preview page displayed with Terms & Condition checkbox
Step7: Admin User clicks on Terms & Condition
Page 30 of 60
System to display Terms & Conditions in a pop-up window
Step8: Admin User checks Terms & Condition and Submit
System to check for all mandatory fields and if any of the mandatory fields are
not entered, display an appropriate error message
If all mandatory details are available, should allow Admin User to submit the
application and to display a new screen with following
i. The system generates Ref No and displays on the screen
ii. A message will be displayed “Please approach home branch for further
processing”
iii. The omnibus document will be generated with all information entered in
onboarding and should be available for download, print, and share over
email
Step9: End Process
Acceptance Please refer below table for validations performed for updating existing information
Criteria
Admin user for existing API banking System should display Onboarding details
customer selects Update Existing tab and should allow the user to edit,
Information Technical Team’s Mobile No, Update API
Selection
In Onboarding details, tab Admin User try Technical Team Email Address should be
to update Technical Team’s Email in a non-editable format
Address
Khata /Khataplus user checks available For Khata/Khataplus users only Enquiry
API’s API’s (Balance Enquiry API) should be
available
SARAL/Vyapaar /Vistar user checks For SARAL/Vyapaar/Vistar corporate
available API’s both Transaction and Enquiry API’s
should be available
In Onboarding details tab Admin User System should display one more option
selects Beneficiary Management API’s for selection “Validate Beneficiary at the
time of Transaction “with a checkbox for
selection
Admin User selects “Validate Beneficiary System should allow the user to select
at the time of Transaction “as Yes and should validate beneficiary details at
the time of transactions
Admin User selects “Validate Beneficiary System should allow the user to select
at the time of Transaction “as No and should not validate beneficiary
In the Transaction Details tab, Admin System should allow the user to enter
Page 31 of 60
User add a new transaction user transaction user details (Name, PAN,
Mobile No, Email)
User details should be saved in the
Omnibus document.
The system should display an alert
message “Updated details will be
applicable post branch approval “
In Transaction details tab, User update System should display an alert message
corporate limit “Updated details will be applicable post
branch approval “
Updated corporate limit will not be

effective for Transactions under process
and will be applicable for transactions
initiated after branch approval
In the Transaction Details tab, Admin System should not allow and should give
User try to enter Corporate Limit more error message as “Corporate Limit
than Bank defined limit cannot be greater than Limit allowed by
Bank”
Admin User edits only integration details For updating only in Integration details
will need approval from GITC and branch
approval will not be required
Admin User enters all mandatory fields, 1. System should allow to submit details
selects Terms & Conditions and submit and should generate an onboarding
the onboarding request reference number
2. The system should also generate an
omnibus document with options to
download/print /email
3. System should display upload omnibus
document option
4. System should display a message
“Please visit your home branch for
approval”
Admin user has updated Transaction For Transaction level and API level detail
details and onboarding details like API changes, Corporate should submit
selection updated board resolution, Changes
should be effective post branch approval
Admin User download Omnibus System should allow to download
document Omnibus document

Page 32 of 60
Admin User upload signed Omnibus System should allow only pdf format for
document upload
Notes All Validations in Onboarding journey should be applicable for updating details
Reference
7.1.6 US06_Postlogin_Check Application Status

User Story US06_Check Application Status in Post Login Journey
As a Corporate Admin User, I should be able to check the status of my organization’s API Banking request
and I should be allowed to resend registration email for my approved onboarding requests
Process Flow Check Status
Step1: Corporate Admin User login to yono business and select API Banking
menu
Step2: Admin User selects Check Status
System should display the Application Status page with below information
1. Application Status along with Date for the corporate which logged in
Admin belongs to
2. Download Omnibus Document
3. Print Omnibus Document
4. Email Omnibus Document
5. Resend Registration Email button
6. Upload signed Omnibus document
Step3: Admin User download Omnibus Document
The system should allow Admin User to download the omnibus document, the
downloaded document should be in PDF format by default
Step4: Admin User Print Omnibus Document
The system should allow Admin User to print the omnibus document
Step5: Admin User email Omnibus Document
The system should allow Admin User to specify email id for sending the Omnibus
document
In case user enter an email id other than the registered email of the corporate,
system to send a copy to the registered email id along with the email id
mentioned
Step6: Admin User selects Resend Registration Email button
The System should send an email to GITC user to resend the invitation email
Page 33 of 60
Step7: Admin User upload a signed omnibus document
The system should allow the user to upload a signed document in .pdf format
Step8: End Process
Criteria
Admin User selects View Status The system should display API banking
Onboarding Application status for the
logged-in Admin User’s corporation
Admin User does not enter valid email The system should display an error
address and try to send the omnibus message “Please enter valid email
document address”
Application status is Approval Pending, Resend Registration Link button should
and Admin User tries to Resend be enabled only for Approved
Registration Link applications.
Admin User enter valid email address and i. The system should send the
try to send the omnibus document Omnibus document on the specified
email address.
ii. In case user enter an email id other
than the registered email of the
corporate, system to send a copy to
the registered email id along with
the email id mentioned
Notes
Reference
7.1.7 US07_Postlogin UAT Completion

Page 34 of 60
Figure 3:UAT Completion
User Story US06_UAT Completion update in Post Login Journey

As a Corporate Admin User, I should be able to update UAT completion and submit required details, so that
I can get access to the production environment.
Process Flow UAT Completion
Step1: Corporate user (Admin and above) login to yono business and select API
Banking menu
Step2: Admin User selects UAT Completion
System should UAT Completion page with below fields
1. Upload UAT Exit Report
2. Upload UAT Security Compliance Certificate
3. Production Details
4. Digital Certificate Upload
5. UAT User Comments
Step3: Admin User Upload UAT Exit Report
System should allow Admin User to upload UAT Exit Report, UAT exit report
should be in Template shared by bank, format should be .pdf
Page 35 of 60
Step4: Admin User Upload Security Compliance Certificate
System should allow Admin User to upload Security Compliance Certificate, this
certificate should be approved by permitted vendors
Step5: Admin User update Production Environment Details
System should display Production IP details if Admin User has entered while
doing onboarding and should allow to update.
In case Production IP details are not entered earlier, system should allow Admin
User to update
Step6: Admin User Upload Digital Certificate for Production environment
System should allow Admin User to upload Digital Certificate as per Standards
Step7: Admin User enters comments and submit details
System should display confirmation message and should generate reference
number
Step8: End Process
Criteria
Admin User upload UAT exit report in System should not allow to upload and
incorrect format (.doc,.xls,.txt) should display error message “Invalid file
format”
Admin User upload UAT exit report in pdf System should allow to upload
format
Admin User does not enter production System should not allow to Submit
details and submit UAT Completion details and give error message
details “Mandatory details are not entered;
request cannot be saved”
Admin User update existing production System should allow Admin User to
environment details (Production update Production IP details
environment details in Onboarding)
Admin User submit UAT Completion System should allow to submit UAT
details Completion details, System should
generate and Reference Number and
should display confirmation message
with Reference Number
Details should be sent to GITC for
approval
Notes
Reference

Page 36 of 60
7.1.8 US08_Token Management
User Story US08_Token Management in yono post login (applicable only for aggregator model)
As a Corporate Admin User, I should be able to generate unique token which will be used in API based
transactions initiated using the ERP provider. I should also be able to define token expiry while generating
the token. I should be able to revoke the token as well.
Type Master setup /Data setup Priority High
Prerequisite Corporate’s onboarding application (with ERP type as “ERP Provider”) is approved by
bank branch.
Process Flow Token Management
Step1: Corporate user login to yono business and select API Banking menu
Onboard Now /Update Existing Application/ Check Status /Token Management
Step2: Admin User selects Token Generation
System should display Token Generation page with below fields
1. Token Generation Button
2. Token Expiry period
3. Revoke Token button
Step3: User selects Token Generation
System should, check if exiting valid token is available
A. If token is available, should display message as “Valid token exists,
please revoke existing token before generating new token”
B. If token is not available, system should allow user to generate new token
and should enable token expiry field
Step4: User submit Token Generation request
A. System should check if expiry period is entered (Max 30 days should be
allowed)
B. If user does not enter expiry period, system should display message as
“Please enter token expiry before submitting the request”
C. If user has entered token expiry period and submit token generation
request
I. System should show confirmation message as “Token
generated successfully” to the User
II. Token value should be shared with Aggregator using service
hosted with yono business (Refer 8.3 Token generation service
for service level details)
Step5: User selects Token Revocation
System should, check if exiting valid token is available
A. If token is available, should display confirmation message as
“Transactions will not be processed until new token is generated, do you
want to cancel the token” with Ok and Cancel options
Page 37 of 60
B. If User selects Cancel on the confirmation message, no action should be
performed
C. If User selects OK on the confirmation message,
I. System should revoke the existing token and a message “Token
cancellation successful” should be displayed
II. Token revocation status should be shared with Aggregator
using service hosted with yono business (Refer 8.4 Token
revocation service for service level details)
D. If token is not available, system should display message as “Valid token
not available for cancellation”
Step6: End Process
Criteria
User does not specify expiry period and System should not allow to generate
try to generate new token token without expiry period and should
display error message as “Please enter
token expiry period”
Transaction request for the corporate is System should reject the transaction with
received post token expiry error as “Token validity expired”
User revokes active token and does not System should reject the transaction with
generate new token before sending error as “Valid token not found”
transaction request
Notes
Reference

Page 38 of 60
7.2 YBBI User Stories
7.2.1 US07_Branch Maker Action
Figure 4:Branch Maker Action
User Story US07_YONOB_Branch Maker Action

As a branch maker user, I should be able to verify and confirm original physical documents for an API Banking
onboarding request and complete my verification task
Type Approval Priority High Effort Estimate High
Process Flow Branch Maker Action
Step1: Branch Maker select API Banking option in the menu
1. System should display Open API Banking requests list page
2. System should also display following tabs to Branch Maker
a. Manage Open API Banking Request
b. View Rejected API Banking Request
Page 39 of 60
c. View All API Banking Request
Step2: Branch Maker selects “View Rejected API Banking Request”
All API Banking Request rejected by the maker branch should be displayed
Step3: Branch Maker selects “View ALL API Banking Request”
All API Banking Request for the maker’s branch should be displayed
Step4: Branch Maker selects an Open API Banking Request
System to display all details entered in yono business for API Onboarding
Step5: Branch Maker Rejects API Banking Onboarding request
1. System should allow to Branch maker to select Reject Reason from
dropdown list
2. System should display message as “Request for API Banking Onboarding
Approval is Rejected with reference number”
3. System should change request status as “Rejected”
4. System should send an email to Corporate’s registered email id for
rejection
Step6: Branch Maker Approves API Banking Onboarding request
(Branch Maker should validate the onboarding application with physical form
submitted)
1. System should display a message to Brach Maker as “Request for API
Banking Onboarding Approval is Approved with reference number”
2. System to display Preview page with following options,
a. Overall Status
b. Regenerate Omnibus Document
c. Email & Print option
d. Omnibus Upload Option
e. KYC Upload option
f. Checklist for API Banking approval with option to tick individual item
3. Post successful document upload and checklist confirmation for all points
(For checklist refer Supporting documents)
4. System should change request status as “Sent for Approval”
5. System should display the request to checker for approval, request status
should be changed as pending with checker
Step7: End Process
Acceptance Please refer below table for validations performed for logged in user as per category
Criteria
Branch Maker selects “Manage Open API System should display Open request for
Banking Request” tab Maker’s branch
Branch Maker selects “View ALL API System should display All API Banking
Page 40 of 60
Banking Request” tab request for Maker’s branch
Branch Maker user search API Banking System should fetch search results as per
request by Corporate ID input criteria
Branch Maker user search API Banking System should fetch API Banking request
request by Reference Number matching with entered Reference
Number
On the Preview page, Branch maker does System should not allow Branch Maker to
not upload omnibus document and submit request for checker approval
approve request
On the Preview page, Branch maker does System should not allow Branch Maker to
not tick checklist for API Banking submit request for checker approval
onboarding request and approve
On the Preview page, Branch maker System should allow Branch Maker to
confirms checklist for API Banking submit request for checker approval
onboarding request and approve
Corporate type is UCB/SCB and corporate Branch maker should reject all API
submit API Banking onboarding request Banking onboarding requests for
following customer type
1. Non-Banking Finance Company
2. SCB
3. UCB
Notes 1. API Banking onboarding approval should be available in CMP OC HYD branch for CMP
Corporates.
2. Branch maker should be able to validate Corporate PAN (as part of O-auth
parameters) using NSDL interface/service (Existing functionality)
Reference 5.1.2 Branch Approval for onboarding (YBBI Approval)
7.2.2 US08_Branch Checker Action

Page 41 of 60
Figure 5:Branch Checker Action
User Story US08_YONOB_Branch Checker Action

As a branch checker user, I should be able to approve or reject API Banking onboarding request
Process Flow Branch Checker Action
Step1: Branch Checker select API Banking option in the menu
System should display Open API Banking requests list page
System should also display following tabs to Branch Checker
1. Manage Open API Banking Request
2. View Rejected API Banking Request
3. View All API Banking Request
Step2: Branch Checker selects “View Rejected API Banking Request”
All API Banking Request rejected by the Checker branch should be displayed
Step3: Branch Checker selects “View ALL API Banking Request”
All API Banking Request for the Checker’s branch should be displayed
Step4: Branch Checker selects an Open API Banking Request
System to display all details entered in yono business for API Onboarding, system
should also display maker comments for the request
Step5: Branch Checker Send Back to Maker Onboarding request
1. System should allow to Checker to send the request back to maker

Page 42 of 60
2. Branch checker should select a reason from dropdown for sending request back
3. Request status to be changed as Send Back to Maker
Step6: Branch Checker Rejects Onboarding request and update the comments
1. System should allow to Checker to reject onboarding request
2. Branch checker should select a reason from Rejection
3. System should send an email to Corporate’s registered email id for rejection
4. Request status should be changed as Rejected
Step7: Branch Checker approves Onboarding request.
1. System should display a confirmation message to Brach Checker along with
Reference Number
2. Request status should be changed as approved by branch
3. System should send email to Corporates register email informing approval for
API banking approval
4. Email to be send to Business and GITC API admin informing branch approval for
the corporate onboarding to api banking.
5. Onboarding application details should be available in YBBI GITC Portal
6. Corporate details should be pushed to Aggregator using API hosted at the
Aggregator end (Ref 8.2 Corporate Details service for interface details)
7. Aggregator to send response with time stamp, Aggregator Corporate ID
mapping will be enabled
Step8: End Process
Criteria
Branch Checker selects “Manage Open System should display Open request for
API Banking Request” tab Checker’s branch
Branch Checker selects “View ALL API System should display All API Banking
Banking Request” tab request for Checker’s branch
Branch Checker search API Banking System should fetch API Banking request
request by Reference Number matching with entered reference number
Branch Checker user search API Banking System should fetch search results as per
request by Corporate ID input criteria
Branch checker rejects API Banking System should not allow to reject request
request without entering Reject Remarks without entering reject remarks
Notes Similar process of API Banking onboarding approval should be available in CMP OC HYD
branch for CMP Corporates.
Page 43 of 60
Reference 5.1.2 Branch Approval for onboarding (YBBI Approval)
7.3 YBBI GITC User Stories
7.3.1 US09_GITC Approval for Onboarding Request
Figure 6:GITC Approval for Onboarding Request
User Story US09_YONOB_GITC Approval for Onboarding Request

Page 44 of 60
As a GITC user, I should be able to verify and confirm onboarding request for API Banking and complete my
verification task
Precondition API Banking onboarding request is approved by Branch. Only approved request should be
available for GITC approval
Process Flow GITC Approval for Onboarding Request
Step1: GITC User select Onboarding Request in the menu
2. System should also display following tabs to GITC User
a. Manage Open API Banking Request
b. View Rejected API Banking Request
c. View All API Banking Request
Step2: GITC User selects “View Rejected API Banking Request”
All API Banking Request rejected by GITC should be displayed
Step3: GITC User selects “View ALL API Banking Request”
All API Banking Request for should be displayed
Step4: GITC User selects an Open API Banking Onboarding Request
System to display all details entered in yono business for the selected Onboarding
Request along with Branch Maker and Checker comments
Step5: GITC User Rejects API Banking Onboarding request
1. System should allow to GITC User to select Reject Reason from dropdown
list
2. System should display message as “Request for API Banking Update
3. System should change request status as “Rejected by GITC”
rejection
Step6: GITC User Approves API Banking Onboarding request
(GITC User should validate the UAT Completion details)
1. System should display a message as “Request for API Banking Onboarding
is Approved with reference number”
a. Overall Status
b. Checklist for API Banking approval with option to tick individual item
3. Post checklist confirmation for all points (For checklist refer Supporting
documents)
4. System should change request status as “Approved”
5. Post Request status is approved:
a. System should trigger an Email with unique link for development
portal registration for UAT Environment to the technical team’s
email id mentioned in onboarding process
Page 45 of 60
b. Email should be sent to Corporate’s registered email id for
technical approval of onboarding request
c. Email should be sent to Business team for technical approval for
the onboarding request
Step7: End Process
Criteria
GITC User selects “Manage Open API System should display Open request for
GITC User selects “View ALL API Banking System should display All API Banking
Request” tab request for Maker’s branch
GITC User search API Banking request by System should fetch search results as per
Corporate ID input criteria
GITC User search API Banking request by System should fetch API Banking request
Reference Number matching with entered Reference
Number
On the Preview page, GITC User does not System should not allow GITC User to
tick checklist for API Banking Onboarding approve request without confirming all
request and approve check list points
Notes For GITC approval, checker action is not required.
Reference 5.1.3 GITC Approval for onboarding (Technical Approval)
7.3.2 US10_GITC Approval for UAT Completion

Page 46 of 60
Figure 7:GITC Approval for UAT Completion
User Story US10_YONOB_GITC Approval for UAT Completion

As a GITC user, I should be able to verify and confirm UAT completion request for API Banking and complete
my verification task
Precondition Corporate had subscribed required API’s and completed integration of its ERP system with
SBI’s API Banking Platform. Corporate has executed all mandatory test cases given by SBI
for UAT
Process Flow GITC Approval for UAT Completion
Step1: GITC User select UAT Completion request in the menu
2. System should also display following tabs to GITC User
d. Manage Open Request
Page 47 of 60
e. View Rejected Request
f. View All Request
Step2: GITC User selects “View Rejected Request”
Step3: GITC User selects “View ALL Request”
Step4: GITC User selects an Open API Banking Request for UAT Completion
1. System should display all details entered in yono business for UAT
completion
2. System should allow to download UAT Exit Report submitted by Corporate
Step5: GITC User Rejects UAT Completion request
1. System should allow to GITC User to enter reject remarks
2. System should display message as “Request for UAT Completion Approval
is Rejected with reference number”
rejection
Step6: GITC User Approves UAT Completion request
(GITC User should validate the UAT Completion details)
1. System should display a message as “Request for API Banking UAT
Completion is Approved with reference number”
c. Overall Status
d. Checklist for API Banking approval with option to tick individual item
documents)
5. Post request status is approved,
a. System should trigger an Email with unique link for development
portal production environment registration to the technical
team’s email id mentioned in onboarding process
b. System should send email to Clients registered email address
informing UAT completion approval and production environment
access
Step7: End Process
Criteria
GITC User selects “Manage Open API System should display Open request for
Page 48 of 60
GITC User selects “View ALL API Banking System should display All API Banking
Request” tab request for Maker’s branch
GITC User search API Banking request by System should fetch search results as per
Corporate ID input criteria
GITC User search API Banking request by System should fetch API Banking request
Reference Number matching with entered Reference
Number
GITC User downloads the UAT Exit Report System should allow to download UAT
uploaded by Corporate Exit Report
On the Preview page, GITC User does not System should not allow GITC User to
tick checklist for API Banking UAT submit request for checker approval
Completion request and approve
Notes For GITC approval, checker action is not required.
7.3.3 US11_GITC Approval for Modification Request

Page 49 of 60
Figure 8: GITC Approval for Modification Request
User Story US11_YONOB_GITC Approval for Technical Modification Request

As a GITC user, I should be able to verify and confirm technical details modification request for existing API
Banking corporate
Precondition Existing Customer of API Banking has changed technical parameter value and submitted
updation requests.
Process Flow GITC Approval for Modification Request

Step1: GITC User select Modification Request option in the menu
System should display Open Modification requests list page

Page 50 of 60
Step2: GITC User selects “View Rejected Request”
Step3: GITC User selects “View ALL API Banking Request”
Step4: GITC User selects a Modification Request
System to display all details entered in yono business for technical updates with
latest values
Step5: GITC User Rejects Modification request
1. System should allow to GITC User to enter reject remarks
2. System should display a message as “Request for API Banking Modification
rejection
Step6: GITC User Approves Modification request
1. System should display a message as “Request for API Banking UAT
Completion is Approved with reference number”
a. Overall Status
b. Checklist for API Banking approval with option to tick individual item
documents)
5. Email should be sent to corporate’s registered email id for approval
Step7: End Process
Criteria
GITC user reject modification request System should not allow to submit
without entering reject remarks rejection without reject remarks
GITC User approves an IP change request API Banking platform should reject all
raised by Corporate incoming API’s from the old IP of Client
ERP and API’s coming from new /latest IP
should be considered for Processing
GITC User rejects an IP change request API Banking platform should reject all
raised by Corporate incoming API’s from the New IP of Client
ERP and API’s coming from old IP should
be considered for Processing
Notes 1. For GITC approval, checker action is not required .

Page 51 of 60
2. For a change in Technical details like Prod IP, Server Certificate change will not
require branch approval on YBBI and Only GITC approval needed
3. Change in any other transactional parameters like Change in Debit Account,
Change in Limit, Change in Admin will need updated Omnibus document and
Branch Approval

Page 52 of 60
7.4 Transaction initiation in Aggregator Model
7.4.1 US12_Payment Initiation in Aggregator Model

User Story US12_ Payment Initiation in Aggregator Model
As a user, I want to initiate a payment request in my ERP providers system using an API hosted by SBI
Type Transaction Priority High Effort Estimate

Precondition 1. Corporate onboarding with the selected Aggregator is approved by bank
2. Corporate has generated token in yono business and token is shared with Aggregator
Process Flow Payment initiation in Aggregator system
Step1: Corporate initiate Payment transaction into the Aggregator’s ERP System
Step2: Corporate request for OTP
OTP request is received at SBI’s API Banking system
A. OTP request validated, and OTP is shared for valid request
I. OTP request should have those mobile numbers which belong to
Transaction Users mentioned in API Banking onboarding
II. User should not be allowed to request OTP more than 5 times in 10 mins
period for the same transaction
B. OTP request is rejected for invalid inputs
Step3: Corporate enters OTP and submit transaction in ERP (Payment initiation
API should be triggered)
API Validation at Bank (Technical Validations)
Following validations are performed for payment initiation API received at bank
Step1: IP whitelisting will be done at ERP LB Level infra internet service layer
A. The request triggered from non-whitelisted IP’s will not be considered
for further processing
B. The request triggered from whitelisted IP’s will be pushed to ERP API
gateway
Step2: ERP API gateway will perform below validations on requests received from
whitelisted IP's
i. API Authentication using Client ID and Secret key of Aggregator
ii. O-auth token authentication (O-Auth token of Aggregator)
iii. ERP API layer validates Digital signature of aggregator /checksum
(hashed payload)
iv. Corporate token validation (Corporate token as part of payload)
A. The validated request will be considered for further execution
B. The invalid request will be rejected with an appropriate error message
Step3: Execution flow of the request

Page 53 of 60
i. RSA decryption of the key received in Header using a private
key of ERP to retrieveAES256 dynamic key
ii. Payload Decryption using AES256 dynamic key
A. Payload decrypted successfully will be sent to further processing
B. Payload having an error in decryption will be rejected
API Validation at Bank (Business Validations)
Following sequence of validations should be performed on payload received from ERP
provider.
Step1: Corporate and Aggregator Mapping Validation
System should validate active mapping of Corporate and Aggregator
A. In case Corporate Id or Aggregator is invalid payment request should be
rejected
B. For valid mapping, payload should be moved next level of validation
Step2: Corporate Token Validation
System should validate corporate token received as part of payload
A. For invalid token payment request should be rejected
B. For valid token, payload should be moved next level of validation
Step3: Other Business Validations (Corporate Account mapping, Limit Validations,
Payment type specific validations)
There will not be any change in existing business validations.
for detailed validations for APIs (Transaction, Balance Enquiry, Payment
Cancellation, MIS, Check Status), refer below documents (Supporting
documents section)
File Name: Solution Document API-based ERP Integration_Phase 1_v1.0 (section 7
User Stories)
File Name: SBI API Banking_Service Specification Document_V1.7

This file contains API specifications (request and response parameters)
Acceptance Please refer below table for Acceptance Criteria details
Criteria Scenario Expected Result

IP whitelisting failed; API received from API not considered for further processing
non-listed IP
IP whitelisting successful, API received API sent to next stage i.e. API
from listed IP Authentication at YB API gateway
API authentication failed for any of below API should not be considered for further
reasons processing and should be rejected
 Client id / Secret key does not match
 The O-Auth token does not match

Page 54 of 60
 Invalid digital signature/checksum
API authentication successful API send to further processing to YB API

layer
Payload decryption failed for any of below Payload having an error in decryption
reason should be rejected
 RSA decryption of the key received
in Header failed
 Payload decryption using AES256
dynamic key failed
Successful payload decryption Payload decrypted successfully should be
sent to further processing
Payload received with invalid Aggregator Transaction request should be rejected
Id with error as “Invalid Aggregator”
Payload received with valid corporate id Transaction request should be rejected
and aggregator id, where no mapping for with error as “Corporate and Aggregator
corporate and aggregator found mapping not found”
Payload received with incorrect O-Auth Payload should be rejected with error as
token for the aggregator and valid “Invalid o-auth token”
corporate token
Payload received with invalid corporate Transaction request should be rejected

token with error as “invalid token”
Payload received with expired corporate Transaction request should be rejected
token with error as “Token expired”
For remaining acceptance criteria for Business validations for different payment
types, refer Supporting documents File Name: Phase 1 solution document (section
7 user stories)
Notes N/A
Reference
8. Interfaces / Service Calls

Following services are in scope for Aggregator based ERP Integration and not required when corporate will
be directly integrating its ERP system with SBI’s API.

Page 55 of 60
8.1 Corporate Validation service
This service hosted at aggregator will be called to validate Corporate details with the aggregator selected
by the corporate at the time of onboarding.
Yono business will call the corporate validation API and Aggregator is required to respond to the API call
made by yono business.
8.2 Corporate Details service
This service hosted at aggregator will be called to push Corporate details captured in yono business
onboarding with the aggregator selected by the corporate at the time of onboarding.
Yono business will call the Corporate Details service API and Aggregator is required to acknowledge the
details pushed by yono business.
8.3 Token generation service
Using this service Corporate’s unique token generated in yono business will be pushed to the aggregator
selected by the corporate at the time of onboarding.
8.4 Token revocation service
Using this service Corporate’s token generated in yono business will be revoked and details will be shared
to Aggregator.
For service level parameter details for above services, please refer: Supporting documents
File Name: SBI API Banking_Aggregator Service Specification Document_V1.1

Page 56 of 60
9. Assumptions and Dependencies
N/A

Page 57 of 60
10. Risks
 As APIC is IBM product, there is limitation for customization of developer portal.
 For developer portal, will have to use security feature provided by the product

Page 58 of 60
11. Supporting documents
# Filename Description Location / Path
1 API Banking _Checklist for Checklist for Branch Maker
Branch Maker and GITC and GITC User
User_V0.1
2 Process Flow for ERP Aggregator model process

Integration flow
3 SBI API Banking_Aggregator Aggregator service

Service Specification specifications
Document_V1.1
4 API banking integration with Approach Note for CINB

legacy Integration
systems_v0.3_24032021
5 Solution Document API-based Phase 1 solution document

ERP Integration_Phase 1_v1.2
6 Offline Onboarding Form Offline Onboarding Form for

Draft_v_0.5_May_2021_2105 API Banking Onboarding
21
7 XD link for UI https://xd.adobe.com/ N/A

view/bf1be61b-35f7-4fc2-
b6b8-0b6c039a19e0-ea48/

Page 59 of 60
12. Abbreviations
# Abbreviations Stands for
1 YONO You Only Need One
2 API Application Program Interface
3 ERP Enterprise resource planning
4 YBBI Yono Business Branch Interface
5 GITC Global Information Technology Center

Page 60 of 60

Solution Document API Based ERP Integration - Postlogin Onboarding Journey v0.9 - 05062021

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Solution Document API Based ERP Integration - Postlogin Onboarding Journey v0.9 - 05062021

Uploaded by

Copyright:

Available Formats

State Bank of India

Project Name-Yono Business –API Banking

Version No.: 0.9

Module Name: yono_Business_API Banking

Solution Document_API Banking Onboarding through yonoBusiness Page 1 of 60

SBI-Business/CCG YB- Mr. Lovesh Abichandani

SBI-IT/SBI GITC-INB Ms. Jaya Pai

SBI-IT/SBI GITC-INB Mr. Pandiarajan A

SBI-IT/SBI GITC-INB Mr. Ashish Mishra

Solution Document_API Banking Onboarding through yonoBusiness Page 2 of 60

Version No Date Author Changes Made

Solution Document_API Banking Onboarding through yonoBusiness Page 3 of 60

5. FUNCTIONAL SPECIFICATION/PROPOSED SOLUTION............................................................................8

5.1 YONO BUSINESS ONBOARDING PROCESS.........................................................................................................8

6.1 PRE-REQUISITES AT ERP SYSTEM.....................................................................................................................11

7.1 POST LOGIN ONBOARDING USER STORIES....................................................................................................13

8. INTERFACES / SERVICE CALLS......................................................................................................................49

8.1 CORPORATE VALIDATION SERVICE...............................................................................................................49

9. ASSUMPTIONS AND DEPENDENCIES............................................................................................................51

11. SUPPORTING DOCUMENTS.........................................................................................................................53

Solution Document – Yono_Business_API-based ERP Integration Post Login Onboarding

Solution Document – Yono_Business_API-based ERP Integration Post Login Onboarding

Figure 1: Steps in API based ERP Integration

5.1 Yono Business Onboarding process

Solution Document – Yono_Business_API-based ERP Integration Post Login Onboarding

5.1.2 Post login onboarding in yono business

5.1.3 Branch Approval for onboarding using YBBI

Solution Document – Yono_Business_API-based ERP Integration Post Login Onboarding

5.1.5 Payment Initiation process (in Aggregator model)

Solution Document – Yono_Business_API-based ERP Integration Post Login Onboarding

6.2 Aggregator Table Structure and Scripts

AGGRTR _EMAIL VARCHAR (30) N

TECH_DEPT_EMAIL VARCHAR (30) Y Id will be used for

UPDATE_COMMENTS VARCHAR (100) N Its mandatory in

Solution Document – Yono_Business_API-based ERP Integration Post Login Onboarding

6.3 Steps for getting SFG Access

Solution Document – Yono_Business_API-based ERP Integration Post Login Onboarding

Solution Document – Yono_Business_API-based ERP Integration Post Login Onboarding

Figure 2:Post login Onboarding

Solution Document – Yono_Business_API-based ERP Integration Post Login Onboarding

Type Master setup /Data setup Priority High

Reference 5.1.1 Aggregator Onboarding

7.1.2 US02_Postlogin_API Banking Tab View

Solution Document – Yono_Business_API-based ERP Integration Post Login Onboarding

Scenario Expected Result

7.1.3 US03_Postlogin Regulator Action for Vistaar Corporates

Solution Document – Yono_Business_API-based ERP Integration Post Login Onboarding

Solution Document – Yono_Business_API-based ERP Integration Post Login Onboarding

7.1.4 US04_Postlogin_Onboarding to API Banking

Solution Document – Yono_Business_API-based ERP Integration Post Login Onboarding

Solution Document – Yono_Business_API-based ERP Integration Post Login Onboarding

3. User to select APIs

Solution Document – Yono_Business_API-based ERP Integration Post Login Onboarding

Step10: Integration details

Solution Document – Yono_Business_API-based ERP Integration Post Login Onboarding

Admin User download Omnibus System should allow to download

Solution Document – Yono_Business_API-based ERP Integration Post Login Onboarding

Updated corporate limit will not be

Solution Document – Yono_Business_API-based ERP Integration Post Login Onboarding

7.1.6 US06_Postlogin_Check Application Status

7.1.7 US07_Postlogin UAT Completion

Solution Document – Yono_Business_API-based ERP Integration Post Login Onboarding