133566407 Sample Business Requirements1

8/13/2019 133566407 Sample Business Requirements1

1/61

Sample-Business-Requirements.docxPage 1 of 61

Document Version : 1.2 Status:Baseline

Published: -/-

ABC BANK (Australia) Ltd

Current Account

And

BPAY and 3rdParty Payments Processing


2/61


Distribution

Business area Name For review and sign off

Banking

Financial Markets Operations

Financial Markets Retail Distribution

Business Intelligence

CIO

Compliance

Operational Risk

Operational Risk

Audit

Finance

Marketing

Marketing

Client Service Centre

Middle Office

Business Systems Testing

IT Infrastructure

IT Infrastructure

Systems Architect

Business Systems

Business Systems

Temenos

Business Systems

Approvals

Business area Name Signature

OperationsBanking

Financial Markets Retail Distribution

Business Systems


3/61


Table of Contents

1. INTRODUCTION ............................................................................................................... 51.1. Document Purpose............................................................. ................................................................. .......... 51.2. Version Management............................................................................................................... ..................... 51.3. Glossary............................................................................................................... ........................................... 51.4. Related Documents............................................................ ................................................................. .......... 62. PRODUCT REQUIREMENTS ......................................................................................... 72.1. In Scope............................................................................................................... ........................................... 72.2. Out of Scope............................................................. ................................................................. ..................... 72.3. Relevant Facts and Assumptions........................................................... ..................................................... 92.4. Current AccountProduct Definition Requirements........................................................... ................... 103. BPAY AND PAY ANYONE FUNCTIONAL REQUIREMENTS............................... 123.1. The scope of the work........................................................ ................................................................. ........ 123.2. Functional Requirements.............................................................. .............................................................. 133.3. BPAY Payments File Structure (Payments from T24 Accounts) .......................................................... 173.4. BPAY File Processing in T24................................................................. .................................................... 253.5. BPAY Acknowledgement & Rejections File Processing in T24............................................................ 254. ONLINE FUNCTIONAL REQUIREMENTS................................................................ 284.1. Summary of Online Configuration Requirements................................................................ ................... 284.2. Online SMS Functional Requirements....................................................................... .............................. 294.2.1. SMS 2-Factor Authentication Requirements....................................................................................... 294.2.2. SMS Alert and Notification Requirements........................................................................ ................... 304.3. Member Limits Requirements.................................................................................................................... 324.4. Mobile Banking Functional Requirements................................................................. .............................. 334.5. Profile (Personal Details) ManagementOnline Banking............................................................ ........ 364.6. GL Requirements..................................................... ................................................................. ................... 364.7. MIS & Mercury Interface Requirements........................................................................................... ........ 374.8. User Interface Redesign for Online Internet and Mobile................................................................ ........ 384.9. Email AlertStatements Available Online........................................................................... ................... 384.10. Finesse Requirements.............................................................. .............................................................. 394.11. Autoforms Requirements....................................................................................................................... 395. ONLINE UPGRADE AND ADDITIONAL ABC ENHANCEMENTS....................... 406. FUTURE CONSIDERATIONS...................................................................................... 44APPENDIX ANEW TRANSACTION TYPES.................................................................... 46APPENDIX B ONLINE GAPS VS ORIGINAL REQUIREMENTS................................. 49APPENDIX CBPAY BUSINESS EVENTS........................................................................ 56Business EventsBPAY and Third Party Payments ................................................ ......................................... 56BPAY PaymentsBusiness Events........................................................ .............................................................. 57Third Party PaymentsBusiness Events............................................................................................................. 59BPAY errors and adjustments................................................................................................................................. 60WORK IN PROGRESS ............................................................................................................. 61

Open Process questions and issues...................................................................................................................... 61


4/61



5/61


1. Introduction

1.1. Document Purpose

This document sets out to describe business requirements for; Introduction of the Current Account products in T24, Finesse and Online

BPAY and third party payments (Pay Anyone) functionality

SMS Authentication and Fraud Monitoring

Mobile Banking functionality and

Online Upgrade including activating ABC enhancements for;

o Multiple signatories capability

Current Account product will be implemented in Finesse and T24 systems. BPAY and third party (pay anyone)

payments functionality will be enabled and integrated with Current Account product.

1.2. Version Management

Version Date Status Amended by Summary of Changes

0.1 21 March 2011 Initial Draft Initial document on BPAY

0.2December

2011Revised Draft

Added Current Account BusinessRequirements

Expanded on BPAY functionality

requirements Added Mobile Banking Functionality

Business Systems Internal review

1.3. Glossary

Term Explanation

Current Account An on call transactional account paying a variable rate of interest. Client can makeBPAY and 3

rdparty payments from their current account.

Overdraft Unsecured or secured line of credit.

Online ABCs online banking system

BPAY An Australian biller payment system.

BPAY View Ability to view BPAY bills via online banking.

PCS Payment Clearing Systemexisting ANZ gateway by which payments to externalbanking institutions are processed.

T24 Core banking system for and FMR.

Westpac ABCssponsoring partner within the BPAY Scheme.

Indue Institution that will facilitate BPAY settlement process with the BPAY sponsoringpartner

3rdParty Payments Payments made to another beneficiarys account (whether that be withinABC or


6/61


Term Explanation

another banking institution).

Pay Anyone The term is used interchangeably with 3rd

Party Payments - Payments made toanother beneficiarys account (whether that be withinABC or another bankinginstitution).

FTP Server Mechanism used when transferring files across networks.

FT Number Funds Transfer number: a unique reference for all funds transfer transactionsprocessed within T24.

STP Straight Through Processingthe ability to process a file automatically from onesystem to another (when transferring) without human intervention.

SMS 2-Factor Authentication A system generated SMS sent to clients containing a unique code to validate theauthenticity of the transaction.

JDE ABCs financial accounting system.

SMS Alerts/ Notification A system generated SMS notifying clients of an event occurring on their account.

1.4. Related Documents

Document Name Document Location


7/61


2. Product Requirements

A Current Account is an on call transactional account paying a variable rate of interest. Current Accounts provide

the client with transactional capability through the online channel specifically allowing BPAY and third partypayments as well as Mobile Banking.

Three types of Current Accounts will be offered to ABC clients;

A deposit only current account

A deposit and overdraft in one current account and

An overdraft only current account

Note: Mobile banking will be made available to all clients with online banking access.

2.1. In Scope

1. Client Current Accounts will be activated in T24 by converting the following existing products;

o Private Call accounts

o Private Select accounts

o POD liberator accounts

o Secured Overdraft Accounts (s-POD) and

o Overdraft Only Accounts (e-POD)

2. Through the Online system, Current Account products will have transactional functionality to;

o

Capture BPAY biller details and make paymentso Capture third party payee details and make payments

3. Online and T24 system will provide functionality to

o Manage biller and payment authentication (Online)

o Manage daily transaction limits (Online)

o Produce BPAY Payment files (T24)

o Processing BPAY acknowledgement and Rejection files (T24)

4. Mobile Banking for all clients with online banking access

Note: As part of the upgrade and turning on of transactional banking functionality clients will have ability for

payment authorization by relevant signatories where there is multiple signatories on the account.

2.2. Out of Scope

1. The following items will be covered as part of the Current Account Phase 2 project

o Linking of Current Account to a credit card or debit card

o Interface to FDI: processing of transactions through ATM or EFTPOS network

o Interface to Indues Orion platform for Fraud monitoring as this is not required until a card (credit ordebit) is linked to the Current Account

2. BPAY View via Online functionality

o Functionality allows clients to view their BPAY bills online through Online


8/61


o Will be covered as a future enhancement

3. Upgrade of ApplyOnline application to Release 3Straight Through Processing

4. System changes to Finesse

o It is assumed there are no changes to Finesse functionality

5. Delegated User Authority in Online will not be switched on

o DUA functionality within Online allows ABC clients to give authorisation access to other parties toperform transactions on their behalf.

o As part of the Online Upgrade, DUA functionality will be available. However for compliance and riskreasons, this functionality will not be switched on as part of Current Account Phase 1

6. Online payment from credit cards to BPAY or third party (Pay Anyone) accounts


9/61


2.3. Relevant Facts and Assumptions

Ref Description

Fact 1 The scope of BPAYfunctionality offered is limited to Paymentsfunctionality. Billingfunctions

are not considered.

BPAY payments enable ABCs online banking clients to make payments to BPAY billers suchas Telstra, local councils, etc.

BPAY billers need to be registered as billers with BPAY and need to comply with specificBPAY rules and procedures regarding the processing of payments to the credit of theirclients accounts.

Fact 2 ABC will join the BPAY scheme as an Associate Member sponsored by a ParticipantMember. This means that payment file submission to, and receipt from, BPAY and financialsettlement will all occur through a third party institution.

The sponsoring institution will be Westpac and Indue will facilitate settlement process for

ABC..

Assumption 1 BPAY and PayAnyone functionality will be made available to Current Accounts maintained onT24system.

Assumption 2 BPAY and Third Party Payments functions will be made available through online banking.Product attributes set and maintained in T24 for a product will determine whether BPAYand/or PayAnyone functionality can be accessed by the client.

Assumption 3 The existing online banking functionality around viewing designated accounts set up andmaintained in T24 will remain unchanged.

Assumption 4 Existing third party nominated accounts set up in T24 will not be automatically set up inOnline as part of the PayAnyone implementation.

Clients will be able to set up and manage their own third party payees through the OnlinePayAnyone functionality.

Assumption 5 Clients will set up and manage their third party payees in Online. ABC staff will not be able toinitiate transactions to these payees, or otherwise maintain the payee records in Online.

Assumption 6 Clients will be able to set up and manage their billers and will be able to make payments tothese billers in Online. ABC staff will not be able to initiate transactions to these payees, orotherwise maintain the payee records in Online.

Assumption 7 PayAnyone transactions will be processed according to the transaction rules already

implemented for Online. Transactions to T24 accounts will be processed end-to-end in T24.Transactions with beneficiary accounts held at other financial institutions will be processedthrough the existing Payment Clearing System process. These transactions will be posted tothe PCS Nostro and be batched in the daily PCS file.


10/61


Assumption 8 BPAY and Third Party payments functionality already exists in Online and only needs to beswitched on. No additional development in Online is required to utilise the functionality.

Assumption 9 Payment authorisation based on multiple signatories already exists in Online and only needsto be switched on. No additional development in Online is required. Development is required

for T24 to send the correct signatory information to Online for transaction processing.

Assumption 10 System generated notifications to clients (e.g. transaction receipts) will use existingfunctionality available in Online.

2.4. Current AccountProduct Definition Requirements

Current Account products will be activated by converting specific existing T24 deposit and overdraft accounts toCurrent Accounts.

Requirement 1 Current Account products will be activated in T24 by flagging existing products aseligible for BPAY & Pay Anyone functionality.

Rationale: To encourage clients to use ABC as their main bank and encourage the full utilisationof limits on overdraft accounts by providing transactional banking on the products. Alsothe deposit only account (Private Call Account) will be renamed accordingly to reflectthe transactional nature of this account and to clearly distinguish it from the Private

Access Account which is purely a call account.

Fit Criterion: BR1.1 Ensure that online BPAY and Pay Anyone payments can be made out of the followingAccounts;

Private Call Account

Private Select Account

Secured Overdraft Account

Overdraft Only Account

POD Liberator

BR1.2 Ensure Private Call Account is renamed as specified below;

Private Call Account to be renamed to Private Current Account (TBAMarketing)

Requirement 2 New and existing products should have the ability to indicate if they are eligible forTransactional banking.

Rationale: Transactional Banking is not offered on all the product offerings in T24 as such requireability to flag eligible accounts. This gives flexibility to define Transactional bankingcapability on new future products.

Fit Criterion: A new flag will be created in T24 Product definition record to indicate if the product iseligible for Transactional banking.

The new flag will be set to Yes on all the products converted to Current Accounts andset to No on all the other products.

Requirement 3 Current Account products originating from Finesse must map correctly to the Hostsystem.

Rationale: To ensure that the correct product with the expected functionality is created in T24 as


11/61


existing mapping rules may not recognise the new product names.

Fit Criterion Finesse to T24 interface changes to ensure Finesse Current Account productscorrectly map to the equivalent T24 Current Account products.


12/61


3. BPAY and Pay Anyone Functional Requirements

3.1. The scope of the work

The implementation of the functionality to pay anyone includingBPAY billers will allow ABC clients to make BPAY

payments and payments to third parties via the online channel. This functionality will be integrated with CurrentAccount products defined in T24 system i.e. the functionality will only be available on the Current Accountproduct.

The diagram below illustrates at a high level the process flow of client requests through the system. Refer toAppendix C for a full analysis of business events emanating from this process flow.

At each stage in the process flow specific events need to be considered.

1. The online banking client access the Online online banking system. For Current Account products, thesystem enables the client to:

Capture details for a BPAY biller (e.g. Biller Code, Customer Reference Number).

Make a single BPAY payment or capture a recurring payment.

Capture details for a third party payee (e.g. name, BSB, account number).

Make a single or recurring payment to a specified third party payee.

2. The Online system will perform the following tasks in support of the clients activities:

Manage biller authentication requirements, i.e. where specific billers require online banking clients toauthenticate themselves before being allowed to pay a bill.

Manage biller code validation for BPAY payments (to ensure only valid details are captured).

Maintain biller lists created up by clients.

Payment

Clearing System

Bpay processing / settlement

System processing

1. OnlineBankingClient

2.1 BankLink

2.2 T24

Bpay

Payment

3.2 Bpay

3.3 Biller(e.g. Telstra, Amex)

Scope of the work

Bpay & PayAnyone

Transaction - submit

Acknowledge /

Reject

3.1 SponsoringInstitution (Indue)

Transact

BPAY Payments File

BPAY

Acknowledgement

PCS Payments file

(3rdParty Payments)


13/61


Maintain third party payee lists created by clients.

Check and manage daily transaction limits.

Online will present transactions to T24 for validation and processing on payment due date.

T24 will perform client, account, transaction and balance checks in line with its standard transaction

processing rules. The system will generate a daily BPAY Payment Details file to enable billers to update theirrecords.

3. INDUE (via Westpac) is the sponsoring Institution for ABC and will representABC within the BPAY Paymentsystem. INDUE will process the ABC files to ensure that payment instructions are promptly provided toBillers. Third Party payments will be processed through the existing Payment Clearing System mechanism.

The scope of the work is in establishing the payment functionality within the ABC systems including activation oftransactional banking on the online channel. Clients with specific products will have access to that functionality.The scope extends to the successful exchange of data and files between ABC and INDUE, and BPAY.

3.2. Functional Requirements

Requirement 5 BPAY payments and Third Party payments functionality needs to be set as allowableonline service for T24 products marked as eligible for Transactional banking i.e.Current Account products.

Rationale: This is to activate the BPAY and Pay Anyone functionality on the online channel. Thisfunctionality will be linked to T24 Current Account products. Clients with such productsare then able to use the functionality to make payments.

Fit Criterion: Products marked with Transactional Banking capability will have Online BPAY and 3rd

Party Payment functionality enabled.

Requirement 6 Online must perform a validity check of Customer reference number and Biller andshow the Biller Name when user inputs a new Biller code.

Rationale: Biller codes must be checked for validity and the Biller name displayed so that usercan confirm that they have selected the correct biller before processing a payment.

Customer reference should be checked to ensure its a valid number for that Biller.

Fit Criterion Online will retrieve the biller name for client verification when a biller code has beenspecified.

Customer Reference number must be a valid reference number for that particularBiller.

Requirement 7 Clients will have the ability to capture future dated and periodic BPAY or 3rdpartypayments.

Rationale: To provide clients with a flexible and automated functionality to manage future datedand periodic payments.

Fit Criterion: Future dated and periodic BPAY or 3rd Party payments will be subject to the followingrules

BR7.1 Clients will have the ability to specify future or periodic payments through Online

BR7.2 Management of the payment (prior to the due date), will be performed in Online.Prior to the due date, clients will have the ability to amend these payments. T24 will not

have any knowledge of these payments.BR7.3 On the day the payment is due, Online will send the payment to T24 for


14/61


15/61


16/61


Fit Criterion: BR14.1 BPAY payments will be listed on a separate withdrawal report

BR14.2 The report will be the same format as existing PCS withdrawal report exceptBSB field will be replaced by Biller Code and Account Number field will bereplaced by Customer Reference Field. The Header should clearly indicate BPAYWithdrawals

BR14.3 The report will be accessed via the Left Hand Menu

Requirement 15 Funding of the settlement account of 3rd party payments will use the existing T24online Withdrawal report.

Rationale: 3rd Party payments are settled through the same Nostro account as PCS transactionshence its logical to have them on the same report for ease of reconciliation of thesettlement Nostro as well as to facilitate funding of this account.

Fit Criterion: BR15.1 3rd

Party payments will be included in the Iclick section of the existing PCS

withdrawal Report.

BR15.2 The Iclick section of the report should be split into 2 sections of DesignatedAccount Payments andThird Party Payments.

Requirement 16 Dishonoured Third party payments will be processed automatically as part of theautomatic PCS dishonour processing i.e. the same transaction used to processpayment dishonours in PCS will be used for Third Party payment dishonours.

Rationale: Third Party payments are processed via PCS thus any returned payments will comethrough the same PCS files. As such same processing should be applied.

Fit Criterion Ensure that dishonours to 3rdparty payments are automatically processed in T24 as inexisting functionality for processing PCS dishonours.

Requirement 17 For BPAY payments out of T24 accounts, BPAY payment files will be produced in T24and submitted to Indue for further processing, refer to section 3.1.2 for further details

Rationale: T24 currently has functionality to produce payments files so we can leverage fromexisting functionality and create BPAY payments files (for all payments out of T24accounts).

Fit Criterion Ensure that BPAY Payment files are produced in T24 for payments out of T24accounts.

Requirement 18 Transactional authorisation for multiple signatory accounts will be managed withinOnline.

Rationale: Multiple signatory authorisation functionality will be activated as part of Onlineupgrade. Functionality reduces risk of unauthorised withdrawals where an account hasmultiple signatories

Fit Criterion: Accounts with multiple signatories specified in T24 will within Online, requireauthorisation from multiple signatories when processing a transaction. Refer to


17/61


Requirement 19 for further details on signing instructions.

Requirement 19 The correct number of signatories for every account used in online banking needs to

be provided by T24 to Online together with the correct list of signatories.

Rationale: Signatory instructions and signatories details are stored on the account on T24. Thenumber of signatories required will be determined in T24 based on the signinginstructions before the message is passed to Online (via WSDL) to enablemanagement of the signing instructions online.

To reduce complexity in implementing multiple signatories functionality for onlinebanking, business agreed to always default 2 to sign where an account requiresauthorisation by multiple signatories. This will be communicated to the client when theyspecify their signing instructions.

Fit Criterion: Authorised signatories and the number of required authorisers will be determined in

T24 on the basis of the Account fields L.SIGN.INSTR and L.SIGN.CUS.BR17.1.1 For accounts:

Count all instances of the multivalue field L.SIGN.CUS todetermine number of signatories on account.

If number of signatories > 1 and L.SIGN.INSTR 'Any 1 to sign'THEN numberOfAuths = 2;

If L.SIGN.INSTR= 'Any 1 to sign' THEN numberOfAuths = 1;

;

BR17.1.2 Term Deposit contracts:

The same rule will apply but based on the details of the connected drawdown account,

i.e. the signing arrangements for term deposits need to be derived from the drawdownaccounts associated with each term deposit contract.

3.3. BPAY Payments File Structure (Payments from T24 Accounts)

Requirement 20 Processing of BPAY Payments made using funds from a T24 account will follow adifferent process to PCS payments.

Rationale: BPAY payment files have a different file structure from PCS files and are submitted toa different settlement account hence the separation.

Also as BPAY transactions are client initiated online transactions, there is no basis tocheck each individual transaction hence straight through authorisation of batches bythe operations team.

Fit Criterion: BR20.1For all BPAY payments out of T24 accounts, T24 will produce a payment filethat has a different file structure from the PCS file (refer Table 1 below). BPAYpayment files will be submitted to Indue for processing into the BPAY system.

Same as in existing PCS functionality, BPAY Payment files will be produced in batchesand several files can be submitted a day.

BR20.2 BPAY payment files will be authorised as batches when releasing the fileswith no requirement to check individual transactions (This requirement will bemanaged via process)


18/61


BR20.3BPAY payment file structure is as defined in Table 1 below.

Requirement 21 All BPAY files (or batches) released on the same day must have a sequence numberassigned.

Rationale: BPAY files released on the same day with the same value date must have a sequencenumber (File Number field) to uniquely identify each file for error handling and orexception processing.

Fit Criterion: BR21.1 Use current T24 batch numbering to derive the sequence number. Thissequence number will be used as part of the file Header record to uniquely identify thefile, refer to field File Number in Table 1 below.

BR21.2. Ensure all BPAY files (or batches) released in a single day are sequencedaccordingly.


19/61


TABLE 1 - BPAY Payments File Structure

Field Name Fieldposition

LengthFormatDescription Value T24 Field

Header Record

Record Type 1 to 2 2 N A code indicating the Header Record 00

File FormatVersion

3 to 4 2 N A numeric identifier for the format of the file to aidchange control. Initial value is 01.

01

Sender Code 5 to 7 3 A The Institution Code of the Payer Institution that

sent the file. Whenever this field is used within aBiller Details File the field will always be set toCSL.

TBA (INDUE)

Receiver Code 8 to 10 3 A The Institution Code that is to receive the file.When used in a Payer Details File this must -always be set to CSL.

CSL

File Creation Date 11 to 18 8 N Format YYYYMMDD. The local date of filecreation.

Date the file is Released

(Format YYYYMMDD)

File Creation Time 19 to 24 6 N Format HHMMSS. The local time of file creation. Time the file is Released(Format HHMMSS)

File Number 25 to 27 3 N The unique file number for the file creation date.The numbers 900 to 999 are reserved for CIPuse.

T24 file sequence number (Refer Requirement 21)

Filler 28 to 292 265 A Leave Blank

Detail Record

Record Type 1 to 2 2 N A code 50 indicating a Payment Instruction

record.

50

PaymentInstruction Type

3 to 4 2 N A code indicating the type of instruction:

05 = Payment

15 = Error Correction

25 = Reversal.

05

1Note that File Numbers for rejected files are not remembered for the file number check. Therefore, the resubmission of a rejected file does notrequire a newfile number value.


20/61




BPAY TransactionType

5 to 5 1 N 0 = original submission,

1 = re-submission (after being rejected).

0

Payer InstitutionCode

6 to 8 3 A The Code representing the Payer Institution. TBA (INDUE)

Payment AccountDetail

9 to 28 20 SPAN Field not used. This will be spaces.The relevant account number of the payer (acredit card or BSB account number), left justifiedwith trailing spaces.

Leave Blank

Country ofPayment

29 to 31 3 A The ISO alphabetic country code in which thePayers Account resides. This will be the code forAustralia.

AUS (for Australia)

State of Payment 32 to 34 3 OA The alphanumeric state in which the Payersaccount resides, if the country has state codes.This may be spaces.

Leave Blank

Currency Code ofPayment

35 to 37 3 A The ISO alphabetic code denoting the currencyof Payment. This must be the code for AustralianDollars.

AUD

Biller Code 38 to 47 10 N The CIP assigned number denoting the Biller, 9digits followed by a Luhn modulus 10 check digit(calculated on the preceding 9 digits).

Biller Codefield on the BPAY FT Transaction

Service Code 48 to 54 7 SPN This will be zero.The CIP assigned number denoting the servicebeing provided by a Biller, 6 digits followed by aLuhn modulus 10 check digit (calculated on thepreceding 6 digits).

Zero

Customer

Reference Number

55 to 74 20 AN The number by which the Biller identifies the

account that is being paid. The last digit (beforethe trailing spaces) is assumed to be a checkdigit. Left justified, filled with trailing spaces. Theleading non-space part must be all numeric.

BPAY Customer Ref field on the BPAY FT

Transaction

Detail Record


21/61




..Cont

Payment Method 75 to 77 3 N A code indicating the method of Payment:

001 = Debit Account

101 = Visa

201 = MasterCard

301 = Other Credit Cards.

001

Entry Method 78 to 80 3 N A code indicating how the details were captured.As from 1 July 2000 this field must contain validvalues from the Entry Method Table. Prior to July2000 the field is user-defined and optional.

004

(Internet/On-lineBanking)

Amount 81 to 92 12 N The amount of the Payment, Reversal or ErrorCorrection, 2 digits of cents implied.

Amount field on the BPAY FT Transaction

(No decimal, add 2 digits for Cents)

TransactionReference Number

93 to 113 21 AN A unique reference number generated by thePayer Institution. It is structured so that the firstthree characters are the alphabetic PayerInstitutionCode, the next eight are YYYYMMDD(the date the payment was made), and the nextset of characters are a numeric PayerInstitution defined Reference Number. Theuse of any remaining space in the field is at thediscretion of the Payer Institution, provided that

only numeric digits are used followed by trailingspaces to fill up the f ield.

Payer Institution Code (TBA)

+ File Release Date (YYYYMMDD)

+ T24 generated Unique code (max 10 digits) used toderive T24 FT Number and Account number.

Detail Record


22/61




..Cont

Original ReferenceNumber

114 to134

21 AN The unique reference code generated by thePayer Institution for the original PaymentInstruction (e.g. this field indicates the uniqueReference Number of a Payment Instruction tobe reversed out). Where an error reference isrelevant (i.e. Error Corrections, Reversals) this isa mandatory field, but the CIP validation will notattempt to match this reference number with theoriginal transaction. Must be space for thePayment Instruction.

Leave Blank

BPAY SettlementDate

135 to142

8 N The date on which the Payer Institution expectsthe Payment to be entered into BPAY Settlement,in YYYYMMDD format.

File Release Date

(Format YYYYMMDD)

Date PaymentAccepted

143 to150

8 N The AEST date that the Payment or ErrorCorrection was processed by the PayerInstitution, in YYYYMMDD format. In the case offuture dated payments this is the future date, notthe date on which the instruction is given by thePayer.

File Release Date

(Format YYYYMMDD)

Time PaymentAccepted

151 to156

6 N The AEST time that the Payment or ErrorCorrection was processed by the PayerInstitution, in HHMMSS format. In the case offuture dated payments this is the future time, notthe time at which the instruction is given by thePayer.

File Release Time

(Format HHMMSS)

Payer Name 40 OA Field not used. This will be spaces.The name ofthe Payer as extracted by the Payer Institutionfrom the Payer Institutions account details.

Leave Blank

AdditionalReference Code

20 OA This is not a required field, but may be present onany Instruction and if present, it must be passedon without validation. There is no requirement forany Payer Institution to capture the AdditionalReference Number and a Biller Institution needonly pass on an Additional Reference Number (totheir Biller) if it has an agreement to do so.

T24 FT Numberof the BPAY Transaction

Detail Record


23/61




..Cont

Error CorrectionReason

3 N For Error Correction Transactions, a codeindicating the reason for generating the ErrorCorrection as defined in the Business Rules andOperational Procedures. Zero if not an ErrorCorrection.

0

Discount Method 3 SPA Field not used. This will be spaces.A code indicating the reason for any discountapplied to the Payment. Code values to beadvised. Space indicates no discount applied.

Leave Blank

DiscountReference

20 SPA Field not used. This will be spaces.A reference code supporting the application ofany discount. Left Justified and filled with trailingspaces .

Leave Blank

Discretionary Data 50 OA Further information required by Biller. Leave Blank

Trailer Record

Record Type 2 N A code 99 indicating the Trailer record. 99

Sender Code 3 A Same value as Header record. TBA (INDUE)

Receiver Code 3 A Same value as Header record. CSL

File Creation Date 8 N Same value as Header record. Same as Header Date the file is Released(Format YYYYMMDD)

File Creation Time 6 N Same value as Header record. Same as Header File Release Time(Format HHMMSS)

File Number 3 N Same value as Header record. Same as Header T24 file sequence number (Refer Requirement 21)

Number ofPayments

9 N The number of Payment Instructions in the file. Total count of Payments in FileWhere Error Correction Reason = zero

Amount ofPayments

15 N The amount of Payment Instructions in the file. Sum Total of Amount field on the BPAY FT of allTransactions where Error Correction Reason = zero

TrailerRecordCont


24/61




Number of ErrorCorrections

9 N The number of Error Correction Instructions inthe file.

Always zero

(No Error correctionrecords expected)

Amount of ErrorCorrections

15 N The amount of Error Correction Instructions in thefile.

Always zero

(No Error correctionrecords expected)

Number ofReversal

9 N The number of Reversal Instructions in the file. Always zero(No Reversal recordsexpected)

Amount ofReversals

15 N The amount of Reversal Instructions in the file. Always zero(No Reversal recordsexpected)

SettlementAmount

15 N Net amount of Payments - Error Corrections Reversals. This field may be signed, or unsignedusing the Sign Indicator to denote the sign.

Sum Total of Amount field on the BPAY FT of allTransactions in file

Settlement SignIndicator

1 A Value space or + if the Settlement Amountabove is positive or is already signed, value - ifthe Settlement Amount is unsigned and negative.

Space

Filler 179 A Leave Blank


25/61


3.4. BPAY File Processing in T24

Requirement 22 The process of releasing BPAY payment files should follow the existing PCS payment

procedure.

Rationale: Although BPAY payment files have a different structure compared with PCS files (andsubmitted to different settlement systems), the functionality should be the same forOperational efficiencies.

Fit Criterion: BR22.1 T24 Left Hand Menu should be modified to include the additional options of;

View BPAY Paymentssame functionality as View Direct Credits Table (onlyBPAY transactions)

Release BPAY Paymentssame functionality as Release Direct Credits (onlyBPAY transactions)

Re-release BPAY Paymentssame functionality as Re-release Direct Credits

(only BPAY transactions)

Authorise BPAY Re-releaseSame functionality as Authorise Re-release (onlyBPAY files)

BR22.2 The same access rights currently existing for releasing PCS payment files willapply to the PBAY payments file. i.e. one BO authoriser will release and another BOauthoriser will authorise the release of the file.

Requirement 23 BPAY Payment files will need to be submitted to Indue for processing of transactions.

Rationale: Indue will poll a specific directory on their FTP server to pick up any BPAY Paymentfiles submitted by ABC hence the need to automate the placing of files on the FTP

server.

All BPAY files that have been released will be available in the BPAY archive directoryand can be accessed manually outside T24 if required to resolve queries.

Fit Criterion: BR23.1 Once the BPAY batch has been released, the BPAY payment file will need tobe submitted to Indue FTP Server so that they can be automatically picked up forpayment processing.

Note: Indue systems will poll this server for any files and automatically pick up BPAYfiles for further processing

BR23.2 All submitted files will need to be archived appropriately in a separate folderspecific to BPAY for trouble shooting and or exception handling.

3.5. BPAY Acknowledgement & Rejections File Processing in T24

ABC will receive an acknowledgement and rejections advice after submission of a BPAY payments file to Indue.This will be effected by means of an email sent to ABC. Acknowledgement of a successful file processing orrejected items will be communicated as part of the content of the email.

Assumption:The acknowledgement and rejections received by ABC will only be for accounts existing on T24.

Requirement 24 Acknowledgement and rejections email will be received by operations team for furtherprocessing.

Rationale: As part of the process to confirm that BPAY files submitted have been received by


26/61


Indue, emails from Indue will be forwarded to the operations team.

Fit Criterion: Ensure an operations team distribution email address is created

Ensure that the confirmation emails from Indue are received by each operations teammember;

Requirement 25 All BPAY rejections emails received need to be archived appropriately.

Rationale: Backup emails for future reference, exception handling and audit purposes.

Fit Criterion: This requirement will be handled via process. All BPAY acknowledgements should bearchived in a specific folder.

Ensure that there is a specific folder to archive BPAY acknowledgements

Requirement 26 BPAY rejections should be easily identifiable on client statements.

Rationale: New transaction specific to BPAY rejections will be used for ease of interpretation onclient statement

Fit Criterion: BR26.1 A new Transaction type specific for processing BPAY rejections ACBD BPAY Payment Returned will be created in T24 refer Appendix A for more details.

BR26.2 BPAY rejections will be processed manually using the new transaction type

Requirement 27 T24 should allow user to manually process a BPAY rejection

Rationale: As the number of BPAY rejections received are minimal, these will be processedmanually by the user i.e. no STP (straight through processing) is required.

Fit Criteria 1. Ensure that user has a Left Hand Menu Item to process BPAY rejections

2. Ensure that the capture screen version accepts the Transaction reference from theemail and defaults all the transaction details (except rejection reason) to process therejection. The rejection reason will be captured by the user.The following fields will be defaulted

the BPAY rejection transaction type to ACBD BPAY Payment Returned Effective date always defaults to Processing date Credit Account Credit Currency Credit Amount Biller code Biller Name Customer Reference Number BPAY Settlement Date

3.. Ensure Debit Account and Currency default to the BPAY Nostro account.

Requirement 28 Manual processing of BPAY payment rejections should not be subject to anyvalidation triggered by restrictions on the account i.e. rejected payments should beprocessed regardless of any restrictions on the account.


27/61


The restrictions should remain unaffected by this processing.

Rationale: To facilitate more efficient processing.

Fit Criterion: Ensure that the system does not restrict user from processing a BPAY rejection whenthe account has account restrictions

Requirement 29 No fee will be automatically charged on rejected BPAY payments.

Rationale: Charging a fee on rejections would discourage clients from using the functionality

Fit Criterion: Ensure that the system does not charge a fee when a rejection is processed.


28/61


4. Online Functional Requirements

4.1. Summary of Online Configuration Requirements

Main Functionality(1

stLevel Menu)

Features of Functionality(2

ndLevel Menu Items)

Exists Description of Functionality

My Accounts(Entity Manager)

N/A Shows entities that user has access to and providesaccess to the user's personal accounts, as well as anyother related entities accounts

Account Manager(Account Details)

Transaction History View Account Details

eStatements View Electronic Statements

Transfers & BPAY Transfer Money

Create PaymentPay Bill (BPAY) New Create BPAY Payment

Transfer History To view history of previous transfers

Pending Payments To View & Edit Pending Payments

BPAYBillers N/A Not required (Out of Scope)

Authorisations View Pending Authorisations

Secure Messages(Messages)

Compose Message To capture a secure message

View Message To view previous messages

SMS SMS Settings New To allow the IBU to activate the SMS alerts service,view and amend their current SMS profile

SMS History New To view previous sms sent from Online

Account Alerts New For IBU to view and amend Account sms Alerts setup

Other Services Change Password Change Online Banking Password

Personal Details View Personal Details

Session Summary View Previous Online Banking sessions

Terms & Conditions Online Banking Terms & Conditions

Mobile Banking New Activate & Change phone number for Mobile Banking

Reset to Default Settings Reset User preferences to default settings


29/61


30/61


Requirement 45 The 2FA authentication SMS message must be configured to contain the appropriateinformation for the client to progress with the transaction.

Rationale: Minimise length of Authentication SMS so that user can easily see the code

Fit Criterion: The authentication SMS message will be configured to contain;

IncludeAuthentication code YESAuthentication Reference YESAction Detail NO

Requirement 46 The following SMS authentication code validation will be configured;

ValidationLength of Authentication code 6Format of Code NumericMaximum Failed Attempts 3

Rationale: Code of 6 Numeric characters will be easy for client to capture.

Fit Criterion: BR46.1 Ensure that SMS authentication code is 6 Numeric characters

BR46.2 Ensure that after 3 attempts of specifying the authentication code, thetransaction is cancelled.

4.2.2. SMS Alert and Notification Requirements

Requirement 47Allow Online Users to setup SMS notification on account payments over a specifiedlimit.

Rationale: To provide user with functionality to manage security of large payments made out oftheir account. Client is notified of such payments immediately as they are processed.

Fit Criterion: Ensure that; The SMS notification can be setup by the Online User. The threshold can be set to any value by the Online User. Notifications can be setup for pending/recurring payments between own accounts,

3rdParty and BPAY.(Batch payment is not configured for ABC) The SMS notification is generated and sent only to the Online User setting up the

payment

Comment: Requirement changed due to gaps with core product, refer to Appendix B for originalrequirement

Requirement 48 . Allow Online Users to setup SMS notification on account for BPAY payments over aspecified limit.

Rationale: To provide user with functionality to manage security of large BPAY payments madeout of their account. Client is notified of such payments immediately as they are

processed.Fit Criterion: Ensure that;

The SMS notification can be setup by the Online User.


31/61


The BPAY Payment threshold can be set to any value by the Online User. The SMS notification is generated and sent only to the Online User setting up the

payment


Requirement 49 Additional SMS services that will be configured are as shown below;Service Service Type Activate

Balance Enquiry Enquiry YES

Transaction Enquiry (10 transactions displayed) Enquiry YES

New Mail received Notification YES

Alert when account has been blocked Notification YES

System Auto reply Alert YES

Pause SMS Service Configuration YES

Delegated User Alerts Alert Not Configuredfor ABC

Rationale: Allow additional notifications and frequently requested account enquiries to beavailable via SMS to enhance client experience.

Fit Criterion: Ensure the following; Balance and Transaction enquiries services are available via SMS Client gets alerts for New Mail received Client gets alert when account is blocked Online client can pause SMS service and none of the above services are

available(However 2FA must still be available after SMS is paused) Delegated User alerts not available as DU functionality will not be configured

for ABC

Comment: Requirement changed due to gaps with core product, refer to Appendix B for original

requirement

Requirement 50 SMS menu options activated are as follows;

Service Activate Rationale

SMS Settings YES Allow View and Change access to SMSservices activated

SMS History YES To view history of previous messages

BPAY Alerts NO Out of Scope -Relates to BPAY View

Quick Access Number YES Allows quick account access codes tobe defined. Access number will be used

in Balance and Transaction enquiry

Rationale: Allow Quick Access Number to facilitate ease SMS enquiries. Allowing user to viewSMS history reduces client enquiries made to CSC. Exclude BPAY alerts as it relatesto BPAY View..

Fit Criterion: Ensure user can: View and change SMS settings View SMS History Can define quick access numbers for use on SMS account enquiries

Ensure a specified Quick Access Number works when an SMS account enquiry usesthe number



32/61


Requirement 51 Allow users to setup SMS notification for future/periodic payments and the notificationwill be sent on the day the payment is processed i.e. on due date. Notifications will besent for any future/periodic payments between Own Accounts,3rd Party and BPAY.

Rationale: Client can set a threshold for which to receive notification of future/periodic paymentswhen they occur as a security feature for the client to monitor large payments madeout of their accounts.

Fit Criterion: Ensure that; Future/periodic payments SMS alerts are only sent for fund transfers exceeding

the threshold. The SMS notification can be setup by the Online User. Notifications can be setup for future/periodic payments between own accounts, 3

rd

Party and BPAY.(Batch payments is not configured for ABC) The threshold can be set to any value by the Online User. The SMS notification is generated and sent only to the User setting up the

payment

SMS notification is generated on the day a future/periodic payment is due.


4.3. Member Limits Requirements

Requirement 52 Member Daily Limits currently configured and managed via Online-WebAdmin shouldbe maintained

Rationale: Member daily limits will be controlled by ABC to minimise risk if fraudulent activitiesoccur on the account

Fit Criterion: BR52.1 Member Daily Limit is currently set at $25K

BR52.2 Ensure that Daily Limit is only changeable via Online-WebAdmin through ourexisting process.

Requirement 53 Configure Daily Limits for BPAY payments , 3r

Party Payments and Transfers toNominated accounts (refer to Fit Criterion for limit default values)

Limits (except Overall Limit) can be decreased at all times by Online Users. However,Limit Increases by Online Users should be prevented, requiring ABC to manage allincreases through ONLINE-WEBADMIN.

Note:For some existing clients, Overall Daily limit is >25k, this data is to be migratedas is and new limits (i.e. Pay Anyone & BPAY & Nominated account transfers) to bedefaulted as specified below.

Rationale: As some clients may be allowed to have a Daily Limit of up to 100K, to reduce the riskof fraudulent transfers of large sums, BPAY, 3

rdParty and Nominated Account

transfers (payments) daily limit will be set to 25K and user cannot increase these limits

thus reducing risk when fraudulent activities occur


33/61


Fit Criterion: Ensure that;

BR53.1 Default Limits are set as in table belowLimit Type Default Limit

Pay Anyone 25K

BPAY 25K

Batch 0

Nominated Transfer 25K

Overall Daily Limit 25K

BR53.2 Ensure that client cannot increasethese limits.

BR53.3 Ensure that client can decreasethese limits as required.

BR53.4 Ensure ABC can manage (i.e. change) these limits via Online-WebAdmin asrequired.

Comment: Requirement changed due to gaps with core product, refer to Appendix B for original

requirement

4.4. Mobile Banking Functional Requirements

Requirement 54 Configure Online to make 'Mobile Banking' service available.

Rationale: Improves customer service by providing an additional channel by which client can dotheir banking via mobile.

Fit Criterion: Ensure that client can activate mobile banking via;

BR54.1 Internet Banking Activation - By signing in to internet banking and selectingthe Online Mobile activation

BR54.2 Mobile Phone Activation - By entering the URL of Online Mobile (as specifiedby ABC CSC) in the mobile phone browser and follow the self activation process usingthe phone.

Requirement 55 Mobile banking logon will not require 2-Factor Authentication.

Rationale: Since we are only allowing payments to Trusted Payees, there is no risk in using client

number and password only to login.Fit Criterion: Ensure that when logging onto Mobile Banking, client Sign-in will only require;

Client number and Password (No token 2FA is required)

Requirement 56 Configure display of 'Mobile Terms and Conditions first time the user logs onto theirMobile phone after activation. Subsequent logins should not display the Terms andconditions on login after activation.

Rationale: This will force every mobile user to view the Terms and conditions of using mobilebanking at least the first time they login.


BR56.1 Terms and Conditions are displayed once the first time user logs onto MobileBanking

BR56.2 Subsequent logins do not display the Terms and conditions on logon


34/61


Requirement 57 Configure Entity Manager functionality for Mobile Banking.

Rationale: To maintain consistency with Online Banking and thus provide better client experience.


Client can access accounts by first selecting the relevant entity samefunctionality as in Online Banking

Requirement 58 Allow Payments to Trusted Payees only. This includes payments to designatedaccounts defined in T24.

Rationale: Mobile payments should only be allowed to be made to trusted payees to minimise riskagainst fraudulent activities


Payments are only to trusted payees i.e. ensure user cannot define new

payees via mobile

Requirement 59 Activate Off-Line many to sign on the Mobile functionality so that payments fromaccounts with multiple signatories can be processed.

Rationale: Mobile does not allow over-the-shoulder authorisation. Mobile always sends out anOffline request for many-to-sign.


BR59.1 Mobile always sends out an Offline request for many-to-sign accounts

BR59.2 The request appears in the Pending Authorisation list on Mobile.

BR59.3 The Authoriser can approve or decline the offline authorisation request.

Requirement 60 Activate email receipts when payments are made via Mobile Banking.

Rationale: To maintain consistency with Online Banking and thus provide better client experience

Fit Criterion: Users can send email to payee and email to self if required by specifying the emailaddresses when processing a payment.

Requirement 61 Any payments processed via Mobile Banking will have the same cut-off times aspayments made via online banking.

Transactions after the cut-off time will be processed for value date of the next businessday same as in existing online transactions.

Rationale: Payments cut-off will be set at 16.00pm consistent with Online Banking cut-off forbetter client experience.

Fit Criterion: Ensure the following cut-off times are implemented on all Mobile payments;

Cut-Off 16.00pm for Value Date = TODAY

Note:Payments to T24 Internal Account are credited to Payee immediately, No Cut-Off time applies.


35/61


36/61


4.5. Profile (Personal Details) ManagementOnline Banking

Requirement 65 Users should not be able to change/update Personal details Online same as in existingconfiguration.

Rationale: This is a security control to ensure that client information is secure and cannot be

changed easily in case of fraudulent activities.

Fit Criterion: BR65.1 Client can only view personal details

BR65.2 Client cannot edit client details

Note: any personal detail changes will follow existing business process.

Requirement 66 Secret Question and Answer functionality needs to be locked from user access ononline banking i.e. user cannot view or change the secret question and answer online.

Rationale: This is an interim solution while ABC finds a resolution to synchronise the 4 systems(Online, Finesse, Domino and T24) that interface and use this field. Refer to Fit

criterion below for further details.

Fit Criterion: Online:

Do not display Secret Question and Answer Online or on Mobile

Finesse Changes:

No changes

T24 Changes:

Require validation to make first Secret question and Answer mandatory and alwaysdefaults to Mothers Maiden Name

Allow user to select other questions and answers if required (not mandatory)

Finesse to Domino Interface

No changes - always interface the Mothers Maiden Name Question and Answer toDomino as in existing functionality

Finesse to T24 Interface

Always interface the Mothers Maiden Name Question and Answer to the first Secretquestion and Answer in T24

4.6. GL Requirements

Requirement 67 The BPAY settlement account on T24 will be mapped to a separate GL JDE object.87133.346M01.S25.

Rationale: For ease accounting and reconciliation of BPAY transactions

Fit Criterion: Ensure that the credit posting of BPAY payments reflect in the new GL object87133.346M01.S25 .


37/61


4.7. MIS & Mercury Interface Requirements

Detailed MIS requirements will be outstanding in this requirement (and thus are excluded from signoff) as there is adependency on the fraud assessment outcome and getting available business resources to define reportingrequirements. However, all information will be made available to MIS from which to build the required fraudreporting requirements

Below are requirements for data to be included in T24 extracts into MIS to enable production of other reports.

Requirement 68 Include all the new transaction types in the MIS JDE Recon extract

Rationale: BPAY and 3rd

Party Transaction Types to be included in the JDE Recon file to enableFinance to resolve reconciliation issues.

Fit Criterion: BR68.1 Replace the word Payment with Withdrawal in Transaction Descriptionswhen including them in MIS extracts i.e.

o Transaction description BPAY Payment should be changed toBPAY Withdrawal

o Transaction Description BPAY Payment Returned should be

changed to BPAY Withdrawal ReturnedBR68.2 MIS JDE recon extract must include the following new transaction types withconverted transaction descriptions as follows;

AC14Online Direct WithdrawalAC15BPAY WithdrawalACBDBPAY Withdrawal Returned

Requirement 69 Include new fields in MIS extracts

Rationale: To facilitate future reporting that will be required

Fit Criterion: BR69.1 Include Transactional Banking flag in the MIS Contract Details extract

BR69.2 Include Statement delivery method field L.PREF.DE.MTHD in the MIScustomer details extract

Requirement 70 Provide functionality for reporting on BPAY transactions

Rationale: To facilitate BPAY transaction reporting and analysis

Fit Criterion: MIS will link to the ONLINE-WEBADMIN database for any BPAY transactionsinformation required for reporting

Requirement 71 BPAY and 3rdParty payment transactions should be included in the existing interfaceto the cash flow management system i.e. interface to Mercury System

Rationale: BPAY and 3rd

Party payments affect the cash flows and therefore should be included inthe T24 interface to the cash flow system.

Fit Criterion: Ensure that the following transactions are included in the mercury interface file;AC14Online Direct WithdrawalAC15BPAY PaymentACBDBPAY Payment Returned


38/61


39/61


4.10. Finesse Requirements

Requirement 75 Provide a single view of client commitments in Finesse by displaying the full portfolio ofproducts a client holds with ABC.

Rationale: A single client view of all commitments a client has with ABC bank will facilitate better

customer service when consultants interact with the client and also facilitates easyevaluation of a clients credit worthiness.

Fit Criterion Ensure that clients full portfolio withABC including products that only exist in T24 suchas Term Deposits, Notice Accounts, Private Access Accounts are displayed in Finesseon the commitments screen. Refer to Change request for further details of therequirement.

4.11. Autoforms Requirements

Requirement 76 Review all existing correspondence to ensure new product names display correctly

Rationale: New Product names may be truncated on client correspondence.

Fit Criterion: Ensure the following correspondence display product names correctly1. Welcome Letters (Experien & PCTI)2. Confirmation of new deposit ( 4 Letters)3. Confirmation of Withdrawal (3 letters)4. Confirmation of Interest Payment5. Reinvestment of funds (2 Letters)6. Token Delivery/ or Replacement Letter (2 Letters)7. Arrears Reminders (3 Letters)8. CDD Pending Letters (2 Letters)9. POD Maturity Letter (2 Letters)10. NCC Dishonor letter11. Forthcoming Maturity of Deposit12. Annual Tax (Experien & PCTI)13. Monthly Account Statement


40/61


5. Online Upgrade and additional ABC Enhancements

Online upgrade will migrate to version 3.86. The upgrade will contain fixes to existing defects and pendingenhancements requested by ABC. Below are the expected changes;

CR-1 [IBI-407] Secure Messages duplicating or not moving to Sent items when replied to.

Description: There have been instances where ONLINE-WEBADMIN User has encountered thefollowing scenarios where the same Secure Message is viewed by two ONLINE-WEBADMIN Users:

It is proposed that whenever a ONLINE-WEBADMIN User encounters a SecureMessage locked by another ONLINE-WEBADMIN User then the application willvalidate if the Secure Message has been actioned (Replied/Forwarded/Deleted) beforeproceeding with the action being performed. If the Secure Message is deleted whilebeing viewed by another ONLINE-WEBADMIN user then it will be removed from thelist only when the list is refreshed manually

Priority: High

CR-2 [IBI-482] Show Date & Time stamp for sent messages

Description: ABC Customer Support using ONLINE-WEBADMIN want to see the Date and Timestamp of a Secure Message that has been responded to by one of their users.

Priority: High

CR-3 [IBI-442] Pending transfers Screen changes

Description: ABC has requested the following changes on the Pending Transfers screen:

1. Widen Available column

2. Reduce From Account column

3. Add column End Date

Priority: Medium

CR-4 [IBI-440] Secure Message Compose Message screen inconsistent with Compose Messagescreen loaded from Transaction History.

Description: In the ABC version of Online the Secure Screen there is an inconsistency in the viewof Create Secure Message screen loaded from two different links:

Transaction History Create Secure Message screen

The inconsistency lies in the display of pre-defined subject drop down menu. While thepre-defined subject dropdown displayed when the Create Secure Message screen isopened from the Transaction History however, if the same screen is loaded directlyfrom the Main Navigation Menu the screen displays an empty field box for the subject,where the client can enter any data for the subject.The proposed solution to provide a consistent behavour is as follows:It is assumed that for each Account type pre-defined subjects will be defined.Furthermore, Online Users will still be able generate General Enquiries or OtherRequests where the Subject will be user enterable.The Account dropdown will list all the accounts along with an entry for GeneralEnquiries.

Priority: Medium


41/61


CR-5 [IBI-441] Customer Limits should not apply for internal transfers between customers ownaccounts

Description: ABC customers using Online Online to make payments between their own accountsutilise their Customer Limits. This has caused confusion among customers who areexpected to make multiple high value payments between their own accounts in a day.It is possible to turn-off limit update for Transfers to Own Accounts (Funds Transfers) in

Online. This also excludes the Transfers to Own Accounts from updating the OverallDaily Limit.If the Funds Transfers Limits are disabled, then the Funds Transfers Limitinformation is not displayed. However, the Overall Daily Limit and un-utilised OverallDaily Limit are always displayed on the Transfers screen even if not updated due toFunds Transfers.Therefore, Transfers between own accounts should not utilise the Customer Limits.

Priority: High (Critical)

CR-6 [IBI-466] Maturity date for LD to be displayed on the Home Page

Description: The Maturity date of a Deposit is an important info for ABC customers. Currently, the

customers are required to navigate the to the Account Details section on theTransaction History to view the Maturity Date. An Unnecessary number of clicks haveto be performed for Online Users to be able to view this information. Furthermore, thedata is incomplete for the deposit account details as it does not contain all informationthe client requires to manage their accounts via the account manager without using theadvanced view.Online Online allows Online Users to access the Account Details via a single click fromthe Home Page. Usually, Online Users view the Account details before transacting.Online Online has introduced the feature to View Loan and Deposit Details. The LoanDetails can be pulled from the Host using the getLoanAccountDetails operation of theWSDL while the Deposit Details can be pulled from the Host using thegetTermDepositDetails operation in the WSDL.

Priority: Medium

CR7 [IBI-483] Right align the Column Headings and Values for all number fields

Description: ABC wanted to implement the standard of Right aligning the Column Headings andAmount values for all number fields.Only the Amount fields and related headings will be Right aligned.

Priority: Medium

CR8 [IBI-484] Transfers navigation changes

Description: In order to improve the usability of functions in Online Online it is required that whenOnline Users select Transfers on Main Navigation Menu, by default the Online Usershould be navigated to Transfer Money screen instead of Payments History List.

Priority: High

CR-9 [IBI-470] Security Questions

OriginalRequirement

ABC Customer Support are required to verify the identification of customer who call-infor assistance. This is done by posing Security Questions to the customer on thephone who are required to answer them.

Currently, the Security Questions are stored and managed on the Host. However thefollowing business drivers require Online to support Security Questions feature:

a. New Customer must be presented Security Questions for them to answer.


42/61


43/61


44/61


6. Future Considerations

Requirement A The customer create workflow for PCTI customers created direct in T24 should createthe Private Current Account as the transactional account not PAA

Rationale: Currently the workflow creates a PAA account as a transactional account into which aclient can make deposits for transfer to Term Deposit or where matured term depositamounts are transferred to pending client instructions.

Requirement B Activate SMS functionality which is triggered by user sign on i.e. when a user islogged in then an SMS Notification is sent to their mobile to alert client that they have

just logged on.

Rationale: Enhances security against hackers who may access the system bypassing the 2-

factor sign in authentication

Requirement C Change Secret Question and answer functionality to allow user to view and change onOnline Banking. Also allow multiple questions to be captured.

Rationale: Changes are required to bring the 4 interfaced systems (Online, Finesse, Domino andT24) in sync with regards to Secret Questions and Answers

Fit Criterion Finesse Changes:

Additional fields to capture 2 extra Secret questions & Answer Questions will be a dropdown list of 14 Questions Additional fields are not Mandatory so user can leave blank

T24 Changes:

Incorporate Validation behind the Secret Question and Answer Multivalue field;

o Multivalue field will be a dropdown list of 15 Questions

o First Question is Mandatory and should always be Mothers MaidenName

o Additional Questions are not Mandatory

Finesse to Domino Interface

Always interface the Mothers Maiden Name Question and Answer to Domino

Do not map the additional Secret Questions and answer to Domino i.e. ifadditional questions are captured in Finesse, ignore these questions wheninterfacing to Domino.

Finesse to T24 Interface

Always interface the Mothers Maiden Name Question and Answer to the firstMultivalue in T24 as it is mandatory in Finesse

if additional questions are captured in Finesse, then map to T24 2ndMultivalue& 3rdMultivalue

Updates done in Finesse, Always Overwrite the 3 Multivalue fields in T24


45/61


Requirement D Activate BPAY Limits functionality and allow limit to be managed by the client/user.

Rationale: Give clients the control to manage how they apportion the member daily limit set byABC bank

Fit Criterion:

Requirement E Activate 3r

Party Limits functionality and allow limit to be managed by the client/user.

Rationale: Give clients the control to manage how they apportion the member limit set by thebank

Requirement F Allow BPAY and 3rd

Party payments functionality to be available for the credit cardproduct.

Rationale: To provide clients with flexibility to use their credit card to make any payments or cash

advances. This is to be inline with industry practice.


46/61


Appendix ANew Transaction Types

The following new transaction types are required in T24;

New Transaction Purpose

1 AC14Online Direct Withdrawal Used to process Online 3r

Party Payments

2 AC15BPAY Payment Used to process Online BPAY Payments

3 ACBDBPAY Payment Returned Used to process Rejected BPAY Payments

Full details of the fields required are as follows;

AC14Online Direct Withdrawal

Tab/Field reference Details DR/CR Narration Length Format

Deposit Tab

Transaction Type AC14Online Direct Withdrawal Online Direct Withdrawal Standard T24Debit Account Valid T24 customer account Standard T24Debit Currency Default to AUD Standard T24Debit Amount Amount to be deposited to client account Standard T24Effective Date Date of Processing Standard T24Source of Instruction Default to other Standard T24Target Account Name Name of account to which funds are transferred Standard T24Target Account BSB BSB of account to which funds are transferred Standard T24Target Account Number Account Number to which funds are transferred Standard T24Lodgement Reference Lodgement Reference captured online by clientComment Tab

Comments Used to hold commentsCharges Tab

Fee Code [None]Fee Type.1Fee Amount.1Nostro

Credit Account Default to ANZ NostroCredit Currency Default to AUD


47/61


Statement NarrativeLine 1 Online Direct Withdrawal Translation of transaction type to statementLine 2 Use reference captured online

by clientExample30/06/09 30/06/09 Online Direct Withdrawal 100.00 30000.00

Invoice 3399

AC15BPAY Payment


Deposit Tab

Transaction Type AC15BPAY Payment BPAY Payment Standard T24

Debit Account Valid T24 customer account Standard T24Debit Currency Default to AUD Standard T24Debit Amount Amount to be deposited to client account Standard T24Effective Date Transaction Effective Date Standard T24Source of Instruction Default to other Standard T24Biller Code Unique Biller Code to which funds are being

sent10 Numeric

Biller Name Biller Name e.g. Telstra 50 AlphanumericCustomer Reference Number Reference number by Which Biller identifies

Account that is being paid20 Alphanumeric

Comment Tab



Credit Account Default to BPAY NostroCredit Currency Default to AUD

Statement NarrativeLine 1 BPAY Payment Translation of transaction type to statementLine 2 Use Biller Name + Ref: +

Customer Reference Number(CRN)

Example30/06/09 30/06/09 BPAY Payment 100.00 30000.00

Telstra Ref: 012221227893


48/61


ACBDBPAY Payment Returned


Deposit Tab

Transaction Type ACBDBPAY Payment Returned BPAY PaymentReturned

Standard T24

Credit Account Valid T24 customer account Standard T24Credit Currency Default to AUD Standard T24Credit Amount Amount to be deposited to client account Standard T24Effective Date Date of Processing Standard T24Source of Instruction Default to other Standard T24Biller Code Unique Biller Code to which funds originally sent 10 Numeric

Biller Name Biller Name e.g. Telstra 50 AlphanumericCustomer Reference Number Reference number by Which Biller identifies

Account that is being paid20 Alphanumeric

BPAY Settlement Date Date when Payment was expected to haveentered BPAY settlement

Standard T24

BPAY Rejection Reason 1st Reason why BPAY payment was rejected 50 AlphanumericRejection Reason 2 2nd Reason why BPAY payment was rejected 50 AlphanumericRejection Reason 3 3rd Reason why BPAY payment was rejected 50 AlphanumericRejection Reason 4 4th Reason why BPAY payment was rejected 50 AlphanumericRejection Reason 5 5th Reason why BPAY payment was rejected 50 AlphanumericComment Tab



Debit Account Default to BPAY NostroDebit Currency Default to AUD

Statement NarrativeLine 1 BPAY Payment Returned Translation of transaction type to statementLine 2 Use 1

stBPAY RejectionReason Description field in FTTransaction

Example30/06/09 30/06/09 BPAY Payment Returned 100.00 30000.00

Customer Reference Number Invalid


49/61


Appendix B Online Gaps vs Original Requirements

Requirement 47 Activate account SMS alert for payments of $10K and above. 10K SMS alert must apply tofuture/periodic payments on the day the payment is processed i.e. on due date

Rationale:To provide security for large amount payments. Client is notified of such payments immediately.

Fit Criterion: BR47.1 An SMS notification is sent to all signatories when an online payment (3rdParty and

designated accounts) $10,000 or more is made.

BR47.2 An SMS notification is sent to all signatories on the day a future/periodic payment of$10,000 or more is processed.

BR47.3 This limit will be managed by ABC and the user cannot change this limit.

Current OnlineBehaviour

In order to be notified of any pending/recurring payment (Between Own Accounts, Batch, 3rdParty and BPAY) on an account over a certain threshold, Online Users can setup "Notification On

Account Payment".

The SMS notification has to be setup by the Online User. The threshold can be set to any value by the Online User. FI cannot define the

threshold. The SMS notification is generated and sent only to the Online User setting up the

payment.

Status This is a new requirement which should go through the Change Request process.Considered out-of-scope for the current release:

BR47.1 BR47.2 BR47.3

ABC Response No Change Request required by ABC. Activate SMS Alert functionality for Online Users as perOnline Standard functionality.


50/61


Requirement 48 Activate account SMS alert for BPAY payments of $10K and above. This Limit will be managed byABC and user cannot change this limit. 10K SMS alert must apply to future/periodic BPAY paymentson the day the payment is processed.

Rationale: To provide security for large amounts of BPAY payments. Client is notified of such a paymentimmediately.

Fit Criterion: BR48.1 An SMS notification is sent to all signatories when a BPAY payment of $10,000 or more ismade.

BR48.2 An SMS notification is sent to all signatories on the day a future/periodic BPAY payment of$10,000 or more is processed

BR48.3 This limit will be managed by ABC and the user cannot change this limit.


In order to be notified of any pending/recurring payment (Between Own Accounts, Batch, 3rd Partyand BPAY) on an account over a certain threshold, Online Users can setup "Notification On AccountPayment".

The SMS notification has to be setup by the Online User. The threshold can be set to any value by the Online User. FI cannot define the

threshold. The SMS notification is generated and sent only to the Online User setting up the

payment.

Status This is a new requirement which should go through the Change Request process.Considered out-of-scope for the current release:

BR48.1 BR48.2 BR48.3

ABC Response No Change Request required by ABC. Activate SMS Alert functionality for Online Users as perOnline Standard functionality


51/61


52/61


53/61


Requirement 51 Future/periodic funds transfers SMS notifications are only sent for amounts of 10K and above

Notification ActivateFuture Dated Internal funds transfer For amount >= 10KPeriodic Internal Funds Transfer For amount >= 10KFuture Dated 3r Party Payments For amount >= 10KPeriodic 3

rParty Payments For amount >= 10K

Future Dated BPAY payments For amount >= 10KPeriodic BPAY payments For amount >= 10K

Rationale: High costs to ABC since clients are currently not charged a fee on their Current Accounts to cover the cost of sending SMS. Also client will beinundated with too many SMS which may result in them not paying enough attention to security SMS

Fit Criterion: Ensure future/periodic payments SMS alerts are only sent for fund transfers of 10K and above.Ensure that the SMS alert for future/periodic payments are sent on the day the payment is processed.


In order to be notified of any pending/recurring payment (Between Own Accounts, Batch, 3rd Party and BPAY) on an account over a certainthreshold, Online Users can setup "Notification On Account Payment".

The SMS notification has to be setup by the Online User. The threshold can be set to any value by the Online User. FI cannot define the threshold. The SMS notification is generated and sent only to the Online User setting up the payment.

Status These are new requirements which should go through the Change Request process. Considered out-of-scope for the currentrelease:

Restricting the alert threshold to a fixed value that cannot be changed by the Online User. Restricting SMS alert to be generated only for Between Own Accounts, 3rd Party and BPAY.

ABC Response No Change Request required by ABC. Disregard requirement to restrict user from making threshold changes. As Batch Paymentsfunctionality is not configured for ABC, I assume no notifications for future/periodic batch payments can be configured in this case. Pleaseconfirm.

Requirement 53 BPAY payments daily Limit and 3rd

Party payments daily Limit will be activated andmanaged by ABC.

Rationale: As some clients may be allowed to have a Daily Limit of up to 100K, to reduce the risk of fraudulent transfers of large sums, BPAY paymentsdaily limit will be set to 25K and 3

rdParty payments daily limit will be set to 25K.

These Limits will be set and managed by ABC and the client will not have ability to change these Limits.

Fit Criterion: BR53.1 Ensure BPAY payments daily limit & 3r Party Payments daily limit are both set to 25K.


54/61


BR53.2 Ensure that client cannot changethese limits.

BR53.3 Ensure ABC can manage (i.e. change) these limits as required.


Limits can be set for BPAY payments & 3rd

Party Payments.

Online Users can change their Daily Limits. Limits can be decreased at all times by Online Users. However, Limit Increases by Online Userscan be prevented, requiring the ABC to manage the same through ONLINE-WEBADMIN.

Therefore, requirements BR53.1, BR53.2 and BR53.3 can be met through a work around.

Status If the workaround is not acceptable then this should be treated as a new requirement which should go through the Change Requestprocess. Considered out-of-scope for the current release:

ABC Response ABC accepts the workaround i.e. Limits can be decreased at all times by Online Users. However, Limit Increases by Online Users should beprevented, requiring ABC to manage all increases through ONLINE-WEBADMIN. Please set defa