streat details

7/31/2019 Streat Details

1/19

One HSBC Account AssemblyCards Processing System

Requirements Specification (BRD)

Version 0.1

25th March 2011

COPYRIGHT GTPL. ALL RIGHTS RESERVED.

No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means,

electronic, mechanical, photocopying, recording, or otherwise, without the prior written permission of GTPL .

Template Version V1.10


2/19


3/19

GTPL Cards Processing System ForeSight Version 0.1

Business Requirements Specification 25th March 2011

Document ControlRole Name E-mail Telephone

ReviewersRole Name

ApprovalRole Name Signature Sign-off Date

Confidential GTPL, 2011 Page 2


4/19



Table of Contents

1.BACKGROUND...........................................................................................................................................................................42. BUSINESS REQUIREMENTS APPROACH........................................................................................................................................5

3. SCOPE..........................................................................................................................................................................................9

THISDOCUMENTPROVIDESTHETOP-LEVELREQUIREMENTS INTURNAREDIVIDEDINSUBSECTIONCLIENTREQUIREMENTS, EXPLOITER

REQUIREMENTS , FACILITATORREQUIREMENTS, MATH FUNCTIONS DEVELOPERREQUIREMENTS , SYSTEMWIDEFUNCTIONALITIES, SYSTEM

MANAGEMENTREQUIREMENTS , PERFORMANCEREQUIREMENTS , TESTINGREQUIREMENTS , OPERATIONALREQUIREMENTS, HUMANENGINEERING

REQUIREMENTS , SECURITYREQUIREMENTS , STANDARDREQUIREMENTS, LEGALANDREGULATORYREQUIREMENTS ........................................9

3.1 PRODUCTS SUPPORTED..........................................................................................................................................................9

DEFINITION.................................................................................................................................................................................13

FUNCTIONAL REQUIREMENTS............................................................................................................................................14

PRODUCT DEFINITION ...........................................................................................................................................................14

FG 1 CARDS PRODUCT DEFINITION............................................................................................................................................14

PRODUCT TYPES........................................................................................................................................................................14

FG 2 PRODUCT TYPES..............................................................................................................................................................14

FR 2.1 BANKCREDIT CARDS - SECURED .................................................................................................................................14

FR 2.2 BANKCREDIT CARDS - UNSECURED..............................................................................................................................15

FR 2.3 BANKCREDIT CARDS - COBRANDED..............................................................................................................................15

ACCOUNT MANAGEMENT......................................................................................................................................................16

FG 3 ACCOUNT MANAGEMENT..................................................................................................................................................16

FR 3.1 ACCOUNT BOARDING...................................................................................................................................................16

FR 3.2 ACCOUNT VERIFICATION...............................................................................................................................................16

CUSTOMER MANAGEMENT...................................................................................................................................................17

FG 4 CUSTOMER MANAGEMENT................................................................................................................................................17

FR 4.1 CUSTOMERBOARDING..................................................................................................................................................17

FR 4.2 CUSTOMERVERIFICATION.............................................................................................................................................17

COLLECTIONS............................................................................................................................................................................17

FG 5 COLLECTIONS..................................................................................................................................................................17

FR 5.1 COLLECTION INITIATION................................................................................................................................................17

FR 5.2 COLLECTION VERIFICATION...........................................................................................................................................17



5/19



1.Background

1.1 GTPL Cards Processing System (ForeSight) Overview

The objective of the GTPL Cards Processing System (named ForeSight) is to develop a comprehensive solution for

meeting the cards processing business processes and product requirements for customers around the globe.

The key goals of the solution are:

- Enhance the customer experience;

- Accelerate cost savings from the standardization of technologies, products and processes on a global

scale; and

- Facilitate the delivery of global propositions.

The Solution has defined the following guiding principles:

Make it Simple and Intuitive

Enable Self Service 24/7

Be driven by the Customer

The Solution has further established the following design rules:

Provide solution at first contact

Build once, modular and Joined Up

ZERO exception processes

Eliminate the need for back office

Give the customer options not products

Eliminate the need for manuals

Incorporate Test and Learn tactics

Provide the same tools to Customer and Staff

Build green (paperless)



6/19



2.Business Requirements Approach

2.1 OverviewThe GTPL Cards processing system will provide a comprehensive cards processing system. It would consist of

several components that work in cohesion.

This document provides the Business requirement specifications for the GTPL Cards Processing System ForeSight.

The functional requirements (FS) for GTPL - ForeSight are documented separately.

2.2 Requirements Source

ForeSight aims to develop a functionally rich cards processing system. The requirements definition has used the cards

processing industry business processing domain as a start point. Requirements driven by process efficiency

considerations and flexibility are customized after internal discussions.

2.3 Purpose of this Document

The purpose of defining the FCS Functional Requirements Document is to lay down a bases for writing

accurate and complete Technical Requirements for the FCS application, and later an FCS Statement of Work

which will be based on these requirements.This document establishes the functional and non-functional (operational, performance, security, etc.)

requirements for the FCS application to provide the needed direction for the design and development.As specific releases are developed, applicable and more precise requirements.

Functions and features that must be delivered as part of GTPL Cards Processing system ForeSight. Although the

requirements aim to remain solution agnostic (that is, no solution to the requirements stated is presumed, which is the

remit of the architecture and engineering teams to determine), it may describe system interactions in a generic mannerwhere it is necessary to establish context.

2.4 Document Conventions

1. This document will be developed in iterations with successive iterations adding additional requirements and a

progressively more granular level of detail.

2. Each document version reflects a new iteration. A major iteration/version is identified with a whole number

e.g. 1, 2 etc. A minor iteration e.g. Draft version for review is identified with a decimal e.g. 0.1, 0.2 etc.

2.5 Accessibility Requirements

2.6 Accuracy Requirements

1. Specify the maximum permitted magnitude of defects in numerical data.

2. Ensure that numerical data represents the true values of the data.

.



7/19


8/19



2.10.12.1 Hardware Reliability

o The probability of a hardware component failing and how long does it take to repair that

component.

2.10.12.2 Software Reliability

o A software component will produce an incorrect output. Software failures are different from

hardware failures in that software does not wear out. It can continue in operation even after an

incorrect result has been produced.

o The system must be implemented in a safe subset of checked using static analysis.

2.10.12.3 Operator Reliability

o How likely is it that the operator of a system will make an error?

2.10.13 Scalability Requirements

2.10.14 Stress Requirements

2.10.15 Supportability Requirements

2.10.16 Throughput Requirement

o The application shall be able to successfully handle 20,000 customer registrations per day.

o At least 98% of the time, the application shall take no more than 0.2 seconds to change focus from a

completed entry field to the next entry field in the same input screen.

o At least 98% of the time, the application shall take no more than 1.3 seconds to change focus from a

completed entry field to the next entry field in the next input screen.

o At least 98% of the time, the application shall take no more than 15 seconds to display any of the required

management reports.

2.11 Security Requirement

o The FCS development team shall communicate with FAS potential users to assure the

security concerns are incorporated and considered during the design for FCS security.

o Prevent unauthorized users from accessing the system.

o Provide physical and remote access control to FCS systems.

o FCS be foreseen of user registration system allowing:

Distinguishing different user roles;

Authorization of users;

Authentication of users.

2.12 Extra Requirement :

Extra Requirements Verifying whether the system achieves a throughput requirement can be difficult and tedious

if the system itself doesnt help, so features for measuring throughput are the first candidates for extra requirements.

Steps to maximize throughput and how we want the system to react when it reaches its throughput limits.



9/19



2.12.1 Probability of failure

o Probability that the system will fail when a service request is made. Useful when demands for

service are intermittent and relatively infrequent.

2.12.2 Failure Consequences

o Reliability measurements do not take the consequences of failure into account.

o Transient faults may have no real consequences but other faults may cause data loss or

corruption and loss of system service

o May be necessary to identify different failure classes and use different metrics for each of these.

The reliability specification must be structured.



10/19



3. Scope

This document provides the top-level requirements in turn are divided in subsection client requirements, exploiterrequirements, facilitator requirements, Math Functions Developer requirements, system wide functionalities, system

management requirements, performance requirements, testing requirements, operational requirements, human engineering

requirements, security requirements, standard requirements, legal and regulatory requirements.

3.1 Products Supported

Within this phase of ForeSight, these requirements are expected to span the following product set:

3.2 In Scope

Bank Credit Cards

Co Branded Cards

Visa Cards

Credit Cards

Maestro Cards

Master cards

ATM Cards

Smart Cards

Debit cards

3.3 Out of Scope

Personal Line of Credit (PLOC)

Home Loans

Gift Card

Prepaid Card

Other Loan products



11/19



4. FCS System Overview

4.1 Model Description

The model of the FCS can be easily understood using the following analogy.

Every small moment of time a definite amount of cash is written off from the debtors account, and

practically simultaneously subscribed to the recipients account. The transfer-rate is defined by mutual predefined

agreements about various time-schedules for installments, or any other parameters necessary. By the

end of the mutually agreed period of time, or by setting in of other pre-agreed conditions, all cash involved has

been transferred from the debtor to the recipient.

4.2 Users Overview

The following list of users outlines a potential FCS users community:

Companies exploiting pipelines can apply FCS to bill their customers for conveying of oil or gas to them.

Data transmission or telephony companies instantly charging for services per time or per transmitted amount of data.

Leasing and real estate industries.

Municipal economy companies, like electricity, water or sewer systems holders.

Government fiscal and budgeting organizations can apply FCS to their specific needs, e.g. pay-per-use of public

infrastructure like roads, polders, etc.; or to some policies and methods, e.g. legal minimum reserves for companies.

Accounting companies, banking and other financial advisors as a facilitator of Instant Payment Flow: making calculations

and forecasts for their clients with one click of the mouse, as various payment flows of a company can be easily

combined in one with varying predefined parameters.

Industry will also take an interest in FCS for performing its credit transactions.

The flexibility of the system also makes it applicable for inter-company payments within large multinational concerns.

4.3 FCS Order Activity Rules

o Credit Card Authorization. Online Formo Credit Card Authorization Successful

o Credit Card Authorization Failure

o Print Slips

o Sales Update on Card



12/19



5. Features/FunctionsThe specifics are detailed within the body of this document, but the features supported have been grouped in to the

following categories:

5.1 Account Lifecycle Management (account closing, re-activation etc)

5.2 Account Servicing(Setting of FAS)

o FC15 Inquiry.

o FC15 Updation.

5.3 Transactions (including clearing and restrictions)

o Processing of account.

o Passing data via tag records.

o Feedback to FAS.

o Pros and cons of batch credit card processing.

5.4 Bulk Processing

o Batch Uploads and Credit Card Processing

o Process batches of credit card transactions

o Batch upload gateway processing

5.5 Exception Management

o Satisfied Account Report

o Collection Tag Reject Report

5.6 Taxation

o tax policy would be set for the next decade

o To keep the overall tax burden low and implement

o To ensure that our regulatory framework remains flexible, proportionate, and up to date

o The guarantee that the 12.5% corporation tax rate will remain

5.7 Operational Accounting

o Analysis of accounting entries, general ledger reports, financial reports, and accounting policies and

procedures.

o Accountants and Certified Public Accountant (CPA).

o Debits and credits directly influence operations.

5.8 Product Dfinition

o Product requirements developed without true customer input.

o A marketing requirement specification (MRS) that is completed late - after development is underway.

o Define an overall strategy for products to guide selection of development projects.

o Define target markets, customers, competitive strengths, and a competition strategy (e.g., competing head-on or

finding a market niche);



13/19



o Products relative to competitive products and identify what will differentiate or distinguish these products from

the competition.

o Rationalize these competing development projects and establish priorities for development projects.

o Provide a high-level schedule of various development projects.

o Estimate development resources and balance project resource requirements with a budget in the overall business

plan.

5.9 Interfaces, Extracts and Reporting

o Classification Reassignment Report

o Collection Tag Audit Report

o Collection Tag Reassignment Report

5.10 Non Functional Requirements (statistics, audit etc)

o Capacity Requirements

o Performance Requirements

o Recovery Requirements

o Security Requirements

o Legal and Regulatory Requirements

o Requirements to Standards

5.11 Interface Requirements

o General FCS External Interface Requirements

o Exploiter/Facilitator Interface Requirements

o Client/Facilitator Interface Requirements

o Inter-Facilitator Interface Requirements

o Exploiter/TTP Interface Requirements

o Client/TTP Interface Requirements

5.12 Testing Requirements

o Standard procedures shall be established to test compliance and conformance of equipment

to be used to facilitate FCS to FCS Standards and to certify interoperability and portability ofinformation systems coupled to FCS systems.

o All corrections to address FCS discrepancies shall be validated through formal regression test

before insertion into the operational FCS systems.

o FCS functionality shall be validated through a formal extensive testing before insertion into the

operational FCS.

5.13 Requirements to documentation

The following are considered within scope:

Credit Limit Management expected to fall within the remit of the Limits & Mitigants stream

Cheque reconciliation expected to be supported through PCM suite



14/19



Payments (Standing Instructions (inc Balance Based), Autopay, Bill Payments, Transfers, Direct Debits)

Paper Payments (Cashiers Orders, Demand Drafts and Traveller Cheques)

Definition

Bank Payer: The bank holding the FCS account of Payer.

Bank Payee: The bank holding the FCS account of Payee.

Clients: Both creditor or debtor who choose to set up their processes of transferring (in case of

creditor) or receiving (in case of debtor) money as instant payments by means of FCS

system.

Exploiter: An organisation which after the development and introduction of FCS will take over the

FCS exploitation responsibilities like marketing, sales, technical and user support,

provisioning of licenses, technical and legal adaptation to new and/or country specific

legislation, all kind of administrative issues, etc.

Facilitator: Authorized companies, e.g. accounting firms, bank specialists or other financial advisors

with necessary knowledge of financial flows, legislation and FCS system which will beable to advise their clients on establishing of their payment according to FCS principles,

assisting with compiling of contracts and definition of payments flow conditions,

supervise instant payment flows of their clients for bookkeeping and administrative

purposes or otherwise facilitate instant payments of their clients.

Installment: One of a number of successive payments in settlement of a debt.

Installment rate: The amount of money paid out per unit time.

Instant payment: A payment arranged according to the Instant Payment Flow principle whereby the

process of money transfer is continuous and permanent within a payment period, as

opposed to the installments principle.

FCS Math FunctionsDevelopers:

Companies with specific mathematical, risk and statistics knowledge which will developspecific payment functions, parameters and boundary conditions as might be requested by

Clients or Facilitators.

FCS TTP: A trusted third party organizing the FCS transaction and redirecting all

necessary information to the other actors.



15/19



Functional Requirements

Product Definition

FG 1 Cards Product Definition

Owner GTPL Business Design Priority

Requirement Details

Credit Card

Additional Info:

Product Types

FG 2 Product Types

FR 2.1 Bank Credit Cards - Secured

Owner One GTPL Business Design Team Priority

Requirement Details

A secured card requires a cash collateral deposit that becomes the credit line for that account.

1) Income document requirement waived off

2) Flexibility to set your own Credit Limit on the basis of the FD amount

3) Term Deposit continues to earn interest

Additional Info: N/A



16/19



FR 2.2 Bank Credit Cards - Unsecured


Requirement Details

1) No Deposit Required

2) Automatic Monthly Credit Bureau Reporting

3) No Application or Processing Fees4) Worldwide Acceptance at Millions of Locations

5) Free 24/7 Online Account Services


FR 2.3 Bank Credit Cards - Cobranded


Requirement Details

1) Minimum net owned fund of Rs.100 crore.

2) The company should have made net profit as per last two years audited balance sheet.

Additional Info/TBD Items : N/A



17/19



Account Management

FG 3 Account Management

FR 3.1 Account Boarding


Requirement Details

1) Collect and validate customer details online

2) Ensure applicant and account data is complete and automatically communicated throughout the process

3) Perform blacklist checks and risk assessment

4) Generate approved new account into a legacy repository

5) Provide a single view into all customer data

Additional Info : Define your organization-specific approvalstage

FR 3.2 Account Verification

Owner One GTPL Business Design Team Priority TBDRequirement Details

1) Clearly recorded.

2) Matched to the Specimen Signature Record of the department.

3) Valid in the period applied; and.

4) Valid for the Fund Centre indicated.

Additional Info : An account verification checklist for processing

acquisition card payment requests



18/19



Customer Management

FG 4 Customer Management

FR 4.1 Customer Boarding

Owner One GTPL Business Design Team Priority TBD

Requirement Details


FR 4.2 Customer VerificationOwner One GTPL Business Design Team Priority TBD

Requirement Details

Financial statement,Third-party reference, such as a credit report,Telephone, web site, and reverse directories.


Collections

FG 5 Collections

FR 5.1 Collection Initiation


Requirement Details

1) Reliable letter of credit (LC) applications.

2) Reducing interest costs through optimal utilization of funds.

Additional Info:

FR 5.2 Collection Verification


Requirement Details

Account information and Card information.

Additional Info: Bank Information



19/19



TERMS AND CONDITIONS:

Term Definition

Attachment A document which is attached to an email to be

sent.

Email Blast An email that is sent to every member on the

contact list.

Secure Credit Card Payment A method of paying by credit card via a website

that ensures credit card information isnt misused

or stolen.

URL Website address www.foresight.com


streat details

Documents