Sample Business Requirements1

Document Version : 1.
Status:Baseline Published: -/-
ABC BANK (Australia) Ltd
Current Account And BPAY and 3rd Party Payments Processing
Sample-Business-Requirements.docx Page 1 of 61
Distribution
Business area 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 Name For review and sign off
Approvals
Business area Operations Banking Financial Markets Retail Distribution Business Systems Name Signature
Table of Contents
1.
1.1. 1.2. 1.3. 1.4.
INTRODUCTION ............................................................................................................... 5
Document Purpose ........................................................................................................................................ 5 Version Management .................................................................................................................................... 5 Glossary .......................................................................................................................................................... 5 Related Documents ....................................................................................................................................... 6
2.
2.1. 2.2. 2.3. 2.4.
PRODUCT REQUIREMENTS ......................................................................................... 7

In Scope .......................................................................................................................................................... 7 Out of Scope................................................................................................................................................... 7 Relevant Facts and Assumptions ................................................................................................................ 9 Current Account Product Definition Requirements.............................................................................. 10
3.
3.1. 3.2. 3.3. 3.4. 3.5.
BPAY AND PAY ANYONE FUNCTIONAL REQUIREMENTS ............................... 12

The scope of the work ................................................................................................................................. 12 Functional Requirements............................................................................................................................ 13 BPAY Payments File Structure (Payments from T24 Accounts) .......................................................... 17 BPAY File Processing in T24 ..................................................................................................................... 25 BPAY Acknowledgement & Rejections File Processing in T24 ............................................................ 25
4.
4.1. 4.2. 4.2.1. 4.2.2. 4.3. 4.4. 4.5. 4.6. 4.7. 4.8. 4.9. 4.10. 4.11.
ONLINE FUNCTIONAL REQUIREMENTS ................................................................ 28

Summary of Online Configuration Requirements ................................................................................... 28 Online SMS Functional Requirements ..................................................................................................... 29 SMS 2-Factor Authentication Requirements ....................................................................................... 29 SMS Alert and Notification Requirements ........................................................................................... 30 Member Limits Requirements .................................................................................................................... 32 Mobile Banking Functional Requirements ............................................................................................... 33 Profile (Personal Details) Management Online Banking .................................................................... 36 GL Requirements ......................................................................................................................................... 36 MIS & Mercury Interface Requirements ................................................................................................... 37 User Interface Redesign for Online Internet and Mobile ........................................................................ 38 Email Alert Statements Available Online .............................................................................................. 38 Finesse Requirements ............................................................................................................................ 39 Autoforms Requirements ....................................................................................................................... 39
5. 6.
ONLINE UPGRADE AND ADDITIONAL ABC ENHANCEMENTS ....................... 40 FUTURE CONSIDERATIONS ...................................................................................... 44
APPENDIX A NEW TRANSACTION TYPES .................................................................... 46 APPENDIX B ONLINE GAPS VS ORIGINAL REQUIREMENTS ................................. 49 APPENDIX C BPAY BUSINESS EVENTS ........................................................................ 56
Business Events BPAY and Third Party Payments ......................................................................................... 56 BPAY Payments Business Events ...................................................................................................................... 57 Third Party Payments Business Events ............................................................................................................. 59 BPAY errors and adjustments................................................................................................................................. 60
WORK IN PROGRESS ............................................................................................................. 61

Open Process questions and issues ...................................................................................................................... 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 0.1 Date 21 March 2011 Status Initial Draft Amended by Summary of Changes Initial document on BPAY 0.2 December 2011 Revised Draft Added Current Account Business Requirements Expanded on BPAY functionality requirements Added Mobile Banking Functionality Business Systems Internal review
1.3. Glossary
Term Current Account Overdraft Online BPAY BPAY View PCS T24 Westpac Indue 3 Party Payments
rd
Explanation An on call transactional account paying a variable rate of interest. Client can make rd BPAY and 3 party payments from their current account. Unsecured or secured line of credit. ABCs online banking system An Australian biller payment system. Ability to view BPAY bills via online banking. Payment Clearing System existing ANZ gateway by which payments to external banking institutions are processed. Core banking system for and FMR. ABCs sponsoring partner within the BPAY Scheme. Institution that will facilitate BPAY settlement process with the BPAY sponsoring partner Payments made to another beneficiarys account (whether that be within ABC or
Term
Explanation another banking institution). The term is used interchangeably with 3 Party Payments - Payments made to another beneficiarys account (whether that be within ABC or another banking institution). Mechanism used when transferring files across networks. Funds Transfer number: a unique reference for all funds transfer transactions processed within T24. Straight Through Processing the ability to process a file automatically from one system to another (when transferring) without human intervention. A system generated SMS sent to clients containing a unique code to validate the authenticity of the transaction. ABCs financial accounting system. A system generated SMS notifying clients of an event occurring on their account.
rd
Pay Anyone
FTP Server FT Number STP SMS 2-Factor Authentication JDE SMS Alerts/ Notification
1.4. Related Documents

Document Name Document Location
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 party payments 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 o o o o o o o o o o Private Call accounts Private Select accounts POD liberator accounts Secured Overdraft Accounts (s-POD) and Overdraft Only Accounts (e-POD)
2. Through the Online system, Current Account products will have transactional functionality to; Capture BPAY biller details and make payments Capture third party payee details and make payments
3. Online and T24 system will provide functionality to Manage biller and payment authentication (Online) Manage daily transaction limits (Online) Produce BPAY Payment files (T24) 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 o o Linking of Current Account to a credit card or debit card Interface to FDI: processing of transactions through ATM or EFTPOS network Interface to Indues Orion platform for Fraud monitoring as this is not required until a card (credit or debit) is linked to the Current Account
2. BPAY View via Online functionality o Functionality allows clients to view their BPAY bills online through Online
Will be covered as a future enhancement
3. Upgrade of ApplyOnline application to Release 3 Straight Through Processing 4. System changes to Finesse o o o It is assumed there are no changes to Finesse functionality
5. Delegated User Authority in Online will not be switched on DUA functionality within Online allows ABC clients to give authorisation access to other parties to perform transactions on their behalf. As part of the Online Upgrade, DUA functionality will be available. However for compliance and risk reasons, 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
2.3. Relevant Facts and Assumptions

Ref Fact 1 Description The scope of BPAY functionality offered is limited to Payments functionality. Billing functions are not considered. BPAY payments enable ABCs online banking clients to make payments to BPAY billers such as Telstra, local councils, etc. BPAY billers need to be registered as billers with BPAY and need to comply with specific BPAY rules and procedures regarding the processing of payments to the credit of their clients accounts. Fact 2 ABC will join the BPAY scheme as an Associate Member sponsored by a Participant Member. This means that payment file submission to, and receipt from, BPAY and financial settlement will all occur through a third party institution. The sponsoring institution will be Westpac and Indue will facilitate settlement process for ABC..
Assumption 1 Assumption 2
BPAY and PayAnyone functionality will be made available to Current Accounts maintained on T24 system. 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 BPAY and/or PayAnyone functionality can be accessed by the client. The existing online banking functionality around viewing designated accounts set up and maintained in T24 will remain unchanged. Existing third party nominated accounts set up in T24 will not be automatically set up in Online as part of the PayAnyone implementation. Clients will be able to set up and manage their own third party payees through the Online PayAnyone functionality.
Clients will set up and manage their third party payees in Online. ABC staff will not be able to initiate transactions to these payees, or otherwise maintain the payee records in Online. Clients will be able to set up and manage their billers and will be able to make payments to these billers in Online. ABC staff will not be able to initiate transactions to these payees, or otherwise maintain the payee records in Online. 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 processed through the existing Payment Clearing System process. These transactions will be posted to the PCS Nostro and be batched in the daily PCS file.
Assumption 7
BPAY and Third Party payments functionality already exists in Online and only needs to be switched on. No additional development in Online is required to utilise the functionality. Payment authorisation based on multiple signatories already exists in Online and only needs to 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. System generated notifications to clients (e.g. transaction receipts) will use existing functionality available in Online.
Assumption 10
2.4. Current Account Product Definition Requirements

Current Account products will be activated by converting specific existing T24 deposit and overdraft accounts to Current Accounts. Requirement 1 Rationale: Current Account products will be activated in T24 by flagging existing products as eligible for BPAY & Pay Anyone functionality. To encourage clients to use ABC as their main bank and encourage the full utilisation of limits on overdraft accounts by providing transactional banking on the products. Also the deposit only account (Private Call Account) will be renamed accordingly to reflect the transactional nature of this account and to clearly distinguish it from the Private Access Account which is purely a call account.
BR1.1 Ensure that online BPAY and Pay Anyone payments can be made out of the following Accounts; 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 (TBA Marketing)
Fit Criterion:
Requirement 2 Rationale:
New and existing products should have the ability to indicate if they are eligible for Transactional banking. Transactional Banking is not offered on all the product offerings in T24 as such require ability to flag eligible accounts. This gives flexibility to define Transactional banking capability on new future products. A new flag will be created in T24 Product definition record to indicate if the product is eligible for Transactional banking. The new flag will be set to Yes on all the products converted to Current Accounts and set to No on all the other products.
Fit Criterion:
Current Account products originating from Finesse must map correctly to the Host system. To ensure that the correct product with the expected functionality is created in T24 as
existing mapping rules may not recognise the new product names. Fit Criterion Finesse to T24 interface changes to ensure Finesse Current Account products correctly map to the equivalent T24 Current Account products.
3. BPAY and Pay Anyone Functional Requirements

3.1. The scope of the work
The implementation of the functionality to pay anyone including BPAY billers will allow ABC clients to make BPAY payments and payments to third parties via the online channel. This functionality will be integrated with Current Account products defined in T24 system i.e. the functionality will only be available on the Current Account product. The diagram below illustrates at a high level the process flow of client requests through the system. Refer to Appendix C for a full analysis of business events emanating from this process flow.
Bpay Payment
3.2 Bpay
BPAY Payments File
3.1 Sponsoring Institution (Indue) 3.3 Biller (e.g. Telstra, Amex)
Scope of the work
Bpay processing / settlement

BPAY Acknowledgement
Transact
Bpay & PayAnyone Transaction - submit PCS Payments file (3rd Party Payments) 2.2 T24
1. Online Banking Client
2.1 BankLink
Acknowledge / Reject
System processing
Payment Clearing System
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, the system 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 to authenticate 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.
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 their records. 3. INDUE (via Westpac) is the sponsoring Institution for ABC and will represent ABC within the BPAY Payment system. INDUE will process the ABC files to ensure that payment instructions are promptly provided to Billers. 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 of transactional 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 allowable online service for T24 products marked as eligible for Transactional banking i.e. Current Account products. This is to activate the BPAY and Pay Anyone functionality on the online channel. This functionality will be linked to T24 Current Account products. Clients with such products are then able to use the functionality to make payments. Products marked with Transactional Banking capability will have Online BPAY and 3 Party Payment functionality enabled.
rd
Rationale:
Fit Criterion:
Online must perform a validity check of Customer reference number and Biller and show the Biller Name when user inputs a new Biller code. Biller codes must be checked for validity and the Biller name displayed so that user can 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 been specified. Customer Reference number must be a valid reference number for that particular Biller.
Requirement 7 Rationale: Fit Criterion:
Clients will have the ability to capture future dated and periodic BPAY or 3 party payments. To provide clients with a flexible and automated functionality to manage future dated and periodic payments. Future dated and periodic BPAY or 3rd Party payments will be subject to the following rules 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
rd
processing. BR7.4 For payments falling on a weekend or public holiday, the payment will be sent to T24 on the business day prior to the non-working day
Client-initiated payments to 3rd Party accounts and BPAY will be subject to the same T24 processing rules as Online Transfers and Payments to Designated Accounts. To comply with AML and risk management regulatory requirements. The same rules will be applied across withdrawals on accounts regardless of the payee. System Checks include; CDD status account-level posting restrictions available balances overdraft limit checks
BPAY & 3rd Party Payments should be easily distinguished on Statements to clients It should be obvious to clients to whom each payment was made. Also this facilitates the easy accounting and reconciliation of BPAY transactions BR9.1 New transaction types will be created within T24 to represent the new BPAY, Third Party and BPAY corrections/ adjustment payments. AC14 Online Direct Withdrawal AC15 BPAY Payment ACBD BPAY Payment Returned Refer to APPENDIX A for a detailed definition of these transaction types. BR9.2 Each transaction type defined above will be used by T24 to decide on the settlement file to which a transaction will belong i.e. BPAY payments file versus Payments Clearing File BR9.3 With Exception to BPAY transactions, transaction reference input by client when capturing an online transaction should be displayed as part of the Transaction Description on the client statement BR9.4 BPAY Transaction description on the statement should include the Customer Reference Number (CRN) Note: CRN identifies the specific BPAY bill being settled
Fit Criterion:
A new Nostro account will be created to account for BPAY payments. To facilitate the accounting for and the reconciliation of BPAY transactions and their settlement within the wider BPAY scheme Ensure that BPAY transaction are processed to the credit of a separate Nostro account in T24
Requirement 11
BPAY transactions and 3 Party payments will adhere to the same business cut-off processing times for existing online transactions.
rd
Rationale:
For Operational efficiencies, BPAY and 3 Party payments processing cut-off time will be set at 16.00pm same as PCS. Note: the cut-off time within INDUE is 17.00pm. In addition, communicating one cut-off time to clients will make it easier for clients to remember. BR11.1 Ensure the following cut-off times are implemented; BPAY: Cut-Off 16.00pm for Value Date = TODAY 3rd Party: Cut-Off 16.00pm for Value Date = TODAY 3rd Party payments to T24 Internal Account : Credited to Payee immediately, No Cut-Off time BR11.2 Transactions after the cut-off time will be processed for value date of the next business day same as in existing online transactions. BR11.3 Online text/ messages on screen for all transactions (specifically BPAY and 3rd Party) will be configured to display the 16:00pm cut-off time.
rd
Fit Criterion:
Requirement 12
Processing of Third party payments to accounts held within T24 will be subjected to different processing rules. These are internal transfers within T24 (no money out the door) as such it is not reasonable to apply cut-off times and value date cut-off rules. If the T24 beneficiary account number is invalid, it will be reported to Online immediately to alert client that the transaction has not been processed.
Rationale:
Fit Criterion:
BR12.1: Third party payments to accounts held in T24 will be credited to the beneficiaries accounts directly, and will not be subject to the cut -off times and valuedating rules mentioned above. These transactions will be excluded from the PCS files in the same way as in existing online internal transfer functionality. BR12.2: If the beneficiary T24 account number specified is incorrect, T24 must return an error message to alert the client (for display in Online).
Requirement 13
Third party payments to accounts held at other institutions will be processed via the Standard Payments Clearing System (PCS). Third Party payments are processed via the PCS system as such it is easier to process these via the same clearing account used by PCS as it facilitates easy accounting and reconciliation of PCS transactions. BR13.1 All payments to 3 Party accounts will follow the existing PCS payment files (and release) process i.e. they will be managed as part of PCS online transactions. BR13.2 Additionally, these payments will be credited to the existing ANZ Payment Clearing System Nostro already defined in T24.
rd
Rationale:
Fit Criterion:
Requirement 14
A separate BPAY withdrawal report is required to enable funding of the BPAY Settlement Account Separate Withdrawal Report to manage BPAY payments vs PCS payments should be provided in T24. This report will be used to fund the BPAY settlement account.
Rationale:
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 except BSB field will be replaced by Biller Code and Account Number field will be replaced by Customer Reference Field. The Header should clearly indicate BPAY Withdrawals 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 T24 online Withdrawal report. 3rd Party payments are settled through the same Nostro account as PCS transactions hence its logical to have them on the same report for ease of reconciliation of the settlement Nostro as well as to facilitate funding of this account. BR15.1 3 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 Designated Account Payments and Third Party Payments.
rd
Rationale:
Fit Criterion:
Requirement 16
Dishonoured Third party payments will be processed automatically as part of the automatic PCS dishonour processing i.e. the same transaction used to process payment dishonours in PCS will be used for Third Party payment dishonours. Third Party payments are processed via PCS thus any returned payments will come through the same PCS files. As such same processing should be applied. Ensure that dishonours to 3 party payments are automatically processed in T24 as in existing functionality for processing PCS dishonours. For BPAY payments out of T24 accounts, BPAY payment files will be produced in T24 and submitted to Indue for further processing, refer to section 3.1.2 for further details T24 currently has functionality to produce payments files so we can leverage from existing functionality and create BPAY payments files (for all payments out of T24 accounts). Ensure that BPAY Payment files are produced in T24 for payments out of T24 accounts.
rd
Rationale: Fit Criterion
Requirement 17
Rationale:
Fit Criterion
Requirement 18
Transactional authorisation for multiple signatory accounts will be managed within Online. Multiple signatory authorisation functionality will be activated as part of Online upgrade. Functionality reduces risk of unauthorised withdrawals where an account has multiple signatories Accounts with multiple signatories specified in T24 will within Online, require authorisation from multiple signatories when processing a transaction. Refer to
Rationale:
Fit Criterion:
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. Signatory instructions and signatories details are stored on the account on T24. The number of signatories required will be determined in T24 based on the signing instructions before the message is passed to Online (via WSDL) to enable management of the signing instructions online. To reduce complexity in implementing multiple signatories functionality for online banking, business agreed to always default 2 to sign where an account requires authorisation by multiple signatories. This will be communicated to the client when they specify their signing instructions.
Rationale:
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 to determine 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 drawdown accounts 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 a different process to PCS payments.
Rationale:
BPAY payment files have a different file structure from PCS files and are submitted to a different settlement account hence the separation. Also as BPAY transactions are client initiated online transactions, there is no basis to check each individual transaction hence straight through authorisation of batches by the operations team. BR20.1 For all BPAY payments out of T24 accounts, T24 will produce a payment file that has a different file structure from the PCS file (refer Table 1 below). BPAY payment 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 batches and several files can be submitted a day. BR20.2 BPAY payment files will be authorised as batches when releasing the files with no requirement to check individual transactions (This requirement will be managed via process)
Fit Criterion:
BR20.3 BPAY payment file structure is as defined in Table 1 below.
All BPAY files (or batches) released on the same day must have a sequence number assigned. BPAY files released on the same day with the same value date must have a sequence number (File Number field) to uniquely identify each file for error handling and or exception processing. BR21.1 Use current T24 batch numbering to derive the sequence number. This sequence number will be used as part of the file Header record to uniquely identify the file, refer to field File Number in Table 1 below. BR21.2. Ensure all BPAY files (or batches) released in a single day are sequenced accordingly.
Fit Criterion:
TABLE 1 - BPAY Payments File Structure Field Name Header Record Record Type File Format Version Sender Code 1 to 2 3 to 4 5 to 7 2 2 3 N N A A code indicating the Header Record
00
Field Length Format Description position
Value
T24 Field
A numeric identifier for the format of the file to aid 01 change control. Initial value is 01. The Institution Code of the Payer Institution that TBA (INDUE) sent the file. Whenever this field is used within a Biller Details File the field will always be set to CSL. The Institution Code that is to receive the file. CSL When used in a Payer Details File this must always be set to CSL. Format YYYYMMDD. The local date of file creation. Format HHMMSS. The local time of file creation. The unique file number for the file creation date. The numbers 900 to 999 are reserved for CIP use.
1
Receiver Code
8 to 10
File Creation Date 11 to 18 File Creation Time 19 to 24 File Number 25 to 27
8 6 3
N N N
Date the file is Released (Format YYYYMMDD) Time the file is Released (Format HHMMSS) T24 file sequence number (Refer Requirement 21)
Filler Detail Record Record Type Payment Instruction Type
28 to 292 265
Leave Blank
1 to 2 3 to 4
2 2
N N
A code 50 indicating a Payment Instruction 50 record. A code indicating the type of instruction: 05 = Payment 15 = Error Correction 25 = Reversal.
05
Note that File Numbers for rejected files are not remembered for the file number check. Therefore, the resubmission of a r ejected file does not require a new file number value.
Field Name
Field Length Format Description position 1 N 0 = original submission, 1 = re-submission (after being rejected). The Code representing the Payer Institution.
Value
T24 Field
BPAY Transaction 5 to 5 Type Payer Institution Code 6 to 8
3 20
TBA (INDUE) Leave Blank
Payment Account 9 to 28 Detail
Country of Payment State of Payment
29 to 31
32 to 34
Currency Code of 35 to 37 Payment Biller Code 38 to 47
10
Service Code
48 to 54
Customer 55 to 74 Reference Number
20
SPAN Field not used. This will be spaces. The relevant account number of the payer (a credit card or BSB account number), left justified with trailing spaces. The ISO alphabetic country code in which the A Payers Account resides. This will be the code for Australia. The alphanumeric state in which the Payers OA account resides, if the country has state codes. This may be spaces. The ISO alphabetic code denoting the currency A of Payment. This must be the code for Australian Dollars. The CIP assigned number denoting the Biller, 9 N digits followed by a Luhn modulus 10 check digit (calculated on the preceding 9 digits). This will be zero. SPN The CIP assigned number denoting the service being provided by a Biller, 6 digits followed by a Luhn modulus 10 check digit (calculated on the preceding 6 digits). The number by which the Biller identifies the AN account that is being paid. The last digit (before the trailing spaces) is assumed to be a check digit. Left justified, filled with trailing spaces. The leading non-space part must be all numeric.
AUS (for Australia)
Leave Blank
AUD
Biller Code field on the BPAY FT Transaction
Zero
BPAY Customer Ref field on the BPAY FT Transaction
Detail Record
Field Name ..Cont Payment Method
Field Length Format Description position 75 to 77 3 N
Value
T24 Field
A code indicating the method of Payment: 001 = Debit Account 101 = Visa 201 = MasterCard 301 = Other Credit Cards.
001
Entry Method
78 to 80
A code indicating how the details were captured. 004 As from 1 July 2000 this field must contain valid (Internet/On-line values from the Entry Method Table. Prior to July Banking) 2000 the field is user-defined and optional. The amount of the Payment, Reversal or Error Correction, 2 digits of cents implied. A unique reference number generated by the Payer Institution. It is structured so that the first three characters are the alphabetic Payer Institution Code, the next eight are YYYYMMDD (the date the payment was made), and the next set of characters are a numeric Payer Institution defined Reference Number. The use of any remaining space in the field is at the discretion of the Payer Institution, provided that only numeric digits are used followed by trailing spaces to fill up the field.
Amount field on the BPAY FT Transaction (No decimal, add 2 digits for Cents) Payer Institution Code (TBA) + File Release Date (YYYYMMDD) + T24 generated Unique code (max 10 digits) used to derive T24 FT Number and Account number.
Amount
81 to 92
12
N AN
Transaction 93 to 113 21 Reference Number
Detail Record
Field Name ..Cont
Field Length Format Description position 21 AN
Value
T24 Field
Original Reference 114 to Number 134
BPAY Settlement Date Date Payment Accepted
135 to 142 143 to 150
Time Payment Accepted
151 to 156
Payer Name
40
OA
Additional Reference Code
20
OA
The unique reference code generated by the Leave Blank Payer Institution for the original Payment Instruction (e.g. this field indicates the unique Reference Number of a Payment Instruction to be reversed out). Where an error reference is relevant (i.e. Error Corrections, Reversals) this is a mandatory field, but the CIP validation will not attempt to match this reference number with the original transaction. Must be space for the Payment Instruction. The date on which the Payer Institution expects the Payment to be entered into BPAY Settlement, in YYYYMMDD format. The AEST date that the Payment or Error Correction was processed by the Payer Institution, in YYYYMMDD format. In the case of future dated payments this is the future date, not the date on which the instruction is given by the Payer. The AEST time that the Payment or Error Correction was processed by the Payer Institution, in HHMMSS format. In the case of future dated payments this is the future time, not the time at which the instruction is given by the Payer. Field not used. This will be spaces.The name of Leave Blank the Payer as extracted by the Payer Institution from the Payer Institutions account details. This is not a required field, but may be present on any Instruction and if present, it must be passed on without validation. There is no requirement for any Payer Institution to capture the Additional Reference Number and a Biller Institution need only pass on an Additional Reference Number (to their Biller) if it has an agreement to do so.
File Release Date (Format YYYYMMDD) File Release Date (Format YYYYMMDD)
File Release Time (Format HHMMSS)
T24 FT Number of the BPAY Transaction
Detail Record
Field Name ..Cont Error Correction Reason
Field Length Format Description position 3 N For Error Correction Transactions, a code indicating the reason for generating the Error Correction as defined in the Business Rules and Operational Procedures. Zero if not an Error Correction. Field not used. This will be spaces. A code indicating the reason for any discount applied to the Payment. Code values to be advised. Space indicates no discount applied. Field not used. This will be spaces. A reference code supporting the application of any discount. Left Justified and filled with trailing spaces . Further information required by Biller.
Value
T24 Field
Discount Method
SPA
Leave Blank
Discount Reference
20
SPA
Leave Blank
Discretionary Data
50
OA
Leave Blank
Trailer Record Record Type Sender Code Receiver Code File Creation Date File Creation Time File Number Number of Payments Amount of Payments Trailer RecordCont
2 3 3 8 6 3 9 15
N A A N N N N N
A code 99 indicating the Trailer record. Same value as Header record. Same value as Header record. Same value as Header record. Same value as Header record. Same value as Header record. The number of Payment Instructions in the file. The amount of Payment Instructions in the file.
99 TBA (INDUE) CSL Same as Header Date the file is Released (Format YYYYMMDD) Same as Header File Release Time (Format HHMMSS) Same as Header T24 file sequence number (Refer Requirement 21) Total count of Payments in File Where Error Correction Reason = zero Sum Total of Amount field on the BPAY FT of all Transactions where Error Correction Reason = zero
Field Name Number of Error Corrections Amount of Error Corrections Number of Reversal Amount of Reversals Settlement Amount Settlement Sign Indicator Filler
Field Length Format Description position 9 N
Value
T24 Field
The number of Error Correction Instructions in Always zero the file. (No Error correction
records expected)
15
The amount of Error Correction Instructions in the Always zero file. (No Error correction
records expected)
The number of Reversal Instructions in the file.
Always zero (No Reversal records expected)
15
The amount of Reversal Instructions in the file.
Always zero (No Reversal records expected)
15
Net amount of Payments - Error Corrections Reversals. This field may be signed, or unsigned using the Sign Indicator to denote the sign. Value space or + if the Settlement Amount Space above is positive or is already signed, value - if the Settlement Amount is unsigned and negative.
Leave Blank
Sum Total of Amount field on the BPAY FT of all Transactions in file
179
3.4. BPAY File Processing in T24

Requirement 22 Rationale: The process of releasing BPAY payment files should follow the existing PCS payment procedure. Although BPAY payment files have a different structure compared with PCS files (and submitted to different settlement systems), the functionality should be the same for Operational efficiencies. BR22.1 T24 Left Hand Menu should be modified to include the additional options of; View BPAY Payments same functionality as View Direct Credits Table (only BPAY transactions) Release BPAY Payments same functionality as Release Direct Credits (only BPAY transactions) Re-release BPAY Payments same functionality as Re-release Direct Credits (only BPAY transactions)
Fit Criterion:
Authorise BPAY Re-release Same functionality as Authorise Re-release (only BPAY files) BR22.2 The same access rights currently existing for releasing PCS payment files will apply to the PBAY payments file. i.e. one BO authoriser will release and another BO authoriser will authorise the release of the file. Requirement 23 Rationale: BPAY Payment files will need to be submitted to Indue for processing of transactions. Indue will poll a specific directory on their FTP server to pick up any BPAY Payment files 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 directory and 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 to be submitted to Indue FTP Server so that they can be automatically picked up for payment processing. Note: Indue systems will poll this server for any files and automatically pick up BPAY files for further processing BR23.2 All submitted files will need to be archived appropriately in a separate folder specific 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 or rejected 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.
Acknowledgement and rejections email will be received by operations team for further processing. As part of the process to confirm that BPAY files submitted have been received by
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 team member;
All BPAY rejections emails received need to be archived appropriately. Backup emails for future reference, exception handling and audit purposes. This requirement will be handled via process. All BPAY acknowledgements should be archived in a specific folder. Ensure that there is a specific folder to archive BPAY acknowledgements
BPAY rejections should be easily identifiable on client statements. New transaction specific to BPAY rejections will be used for ease of interpretation on client statement 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
T24 should allow user to manually process a BPAY rejection As the number of BPAY rejections received are minimal, these will be processed manually by the user i.e. no STP (straight through processing) is required. 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 the email and defaults all the transaction details (except rejection reason) to process the rejection. 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.
Fit Criteria
Requirement 28
Manual processing of BPAY payment rejections should not be subject to any validation triggered by restrictions on the account i.e. rejected payments should be processed regardless of any restrictions on the account.
The restrictions should remain unaffected by this processing. Rationale: Fit Criterion: To facilitate more efficient processing. Ensure that the system does not restrict user from processing a BPAY rejection when the account has account restrictions
No fee will be automatically charged on rejected BPAY payments. Charging a fee on rejections would discourage clients from using the functionality Ensure that the system does not charge a fee when a rejection is processed.
4. Online Functional Requirements

4.1. Summary of Online Configuration Requirements
Main Functionality st (1 Level Menu)
My Accounts (Entity Manager)
Features of Functionality nd (2 Level Menu Items)

N/A
Exists
Description of Functionality
Shows entities that user has access to and provides access to the user's personal accounts, as well as any other related entities accounts
Account Manager (Account Details)
Transaction History eStatements

New
View Account Details View Electronic Statements
Transfers & BPAY
Transfer Money Pay Bill (BPAY) Transfer History Pending Payments BPAY Billers Authorisations
Create Payment Create BPAY Payment To view history of previous transfers To View & Edit Pending Payments Not required (Out of Scope) View Pending Authorisations

N/A
Secure Messages (Messages)
Compose Message View Message
To capture a secure message To view previous messages
SMS
SMS Settings SMS History Account Alerts
New New New
To allow the IBU to activate the SMS alerts service, view and amend their current SMS profile To view previous sms sent from Online For IBU to view and amend Account sms Alerts setup
Other Services
Change Password Personal Details Session Summary Terms & Conditions Mobile Banking Reset to Default Settings

New
Change Online Banking Password View Personal Details View Previous Online Banking sessions Online Banking Terms & Conditions Activate & Change phone number for Mobile Banking Reset User preferences to default settings
4.2. Online SMS Functional Requirements

4.2.1.SMS 2-Factor Authentication Requirements Requirement 40 Rationale: 2-Factor authentication will be enacted for newly added or amended 3 Party Payees. 3 Party payments functionality means an online user can create a new payee and make payment which increases risk of fraud if there is no verification. 2-factor Authentication introduces verification which will ensure that new payees are created by authorised users only thus minimise the risk. BR40.1 2FA message (SMS or note on screen for clients with no mobile number) will rd be invoked for new or amended 3 Party account before making payment BR40.2 2FA message (SMS or note on screen for clients with no mobile number) will rd be invoked for a new or amended 3 Party payee when being paid for the first time
rd rd
Fit Criterion:
2-Factor authentication should not be configured for new billers. Online user should be able to add a new biller and make a payment without authentication. As users may wish to Pay several billers at the same time, it becomes cumbersome if they have to authenticate each new biller thus affecting the client experience. Also ABC considers paying billers less risky in terms of fraud activities. Newly or amended BPAY Billers will not require authentication. i.e. no SMS is sent out or text displayed on screen.
Fit Criterion:
3 Party payee authentication will be configured to be done BEFORE authorisation of transaction i.e. for first payment authentication scenario For efficiency especially where multiple signatories are required, the transaction will rd only go to the other signatories once the new 3 Party payee is trusted. Ensure that for multiple signatories, new 3 Party payees are authenticated first by the initiator before authorisation of the payment by other signatories
rd
rd
Fit Criterion:
Requirement 43 Rationale: Fit Criterion
Newly added 3 Party Payees will be cross-checked against the existing list of trusted payees. If payments have been processed to the same account previously, then another authentication is redundant. rd Online will be configured to validate new 3 Party Payee BSB number and Account number against trusted payees and if a match exists on a trusted payee, then the new payee is deemed trusted. No validation of payee reference is required as part of the matching process.
rd
Authentication of daily limits is not required and will not be configured. Daily limits for payments to un-trusted payees as well as a separate daily limit to track payments to trusted payees is deemed unnecessary as other controls and notifications will be configured. Online will need to be configured to have client defined limits switched OFF and untrusted payee limits switched OFF.
Fit Criterion:
Requirement 45
The 2FA authentication SMS message must be configured to contain the appropriate information for the client to progress with the transaction. Minimise length of Authentication SMS so that user can easily see the code The authentication SMS message will be configured to contain; Include YES YES NO
Rationale: Fit Criterion:
Authentication code Authentication Reference Action Detail Requirement 46
The following SMS authentication code validation will be configured; Validation 6 Numeric 3
Length of Authentication code Format of Code Maximum Failed Attempts Rationale: Fit Criterion:
Code of 6 Numeric characters will be easy for client to capture. BR46.1 Ensure that SMS authentication code is 6 Numeric characters BR46.2 Ensure that after 3 attempts of specifying the authentication code, the transaction is cancelled.
4.2.2. SMS Alert and Notification Requirements Requirement 47 Allow Online Users to setup SMS notification on account payments over a specified limit. To provide user with functionality to manage security of large payments made out of their account. Client is notified of such payments immediately as they are processed. 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, rd 3 Party 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 Requirement changed due to gaps with core product, refer to Appendix B for original requirement
Rationale:
Fit Criterion:
Comment:
Requirement 48
. Allow Online Users to setup SMS notification on account for BPAY payments over a specified limit. To provide user with functionality to manage security of large BPAY payments made out of their account. Client is notified of such payments immediately as they are processed. Ensure that; The SMS notification can be setup by the Online User.
Rationale:
Fit Criterion:
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
Comment:
Requirement changed due to gaps with core product, refer to Appendix B for original requirement
Requirement 49
Additional SMS services that will be configured are as shown below;

Service Balance Enquiry Transaction Enquiry (10 transactions displayed) New Mail received Alert when account has been blocked System Auto reply Pause SMS Service Delegated User Alerts Service Type Enquiry Enquiry Notification Notification Alert Configuration Alert Activate YES YES YES YES YES YES Not Configured for ABC
Rationale:
Allow additional notifications and frequently requested account enquiries to be available via SMS to enhance client experience. 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 Requirement changed due to gaps with core product, refer to Appendix B for original requirement
Fit Criterion:
Comment:
Requirement 50
SMS menu options activated are as follows;

Service SMS Settings SMS History BPAY Alerts Quick Access Number Activate YES YES NO YES Rationale Allow View and Change access to SMS services activated To view history of previous messages Out of Scope -Relates to BPAY View Allows quick account access codes to be defined. Access number will be used in Balance and Transaction enquiry
Rationale:
Fit Criterion:
Allow Quick Access Number to facilitate ease SMS enquiries. Allowing user to view SMS history reduces client enquiries made to CSC. Exclude BPAY alerts as it relates to BPAY View. . 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 uses the number Requirement changed due to gaps with core product, refer to Appendix B for original requirement
Comment:
Requirement 51
Allow users to setup SMS notification for future/periodic payments and the notification will be sent on the day the payment is processed i.e. on due date. Notifications will be sent for any future/periodic payments between Own Accounts,3rd Party and BPAY. Client can set a threshold for which to receive notification of future/periodic payments when they occur as a security feature for the client to monitor large payments made out of their accounts. 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. rd Notifications can be setup for future/periodic payments between own accounts, 3 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 . Requirement changed due to gaps with core product, refer to Appendix B for original requirement
Rationale:
Fit Criterion:
Comment:
4.3. Member Limits Requirements

Requirement 52 Rationale: Fit Criterion: Member Daily Limits currently configured and managed via Online-WebAdmin should be maintained Member daily limits will be controlled by ABC to minimise risk if fraudulent activities occur on the account BR52.1 Member Daily Limit is currently set at $25K BR52.2 Ensure that Daily Limit is only changeable via Online-WebAdmin through our existing process.
Requirement 53
Configure Daily Limits for BPAY payments , 3 Party Payments and Transfers to Nominated 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 all increases through ONLINE-WEBADMIN. Note: For some existing clients, Overall Daily limit is >25k, this data is to be migrated as is and new limits (i.e. Pay Anyone & BPAY & Nominated account transfers) to be defaulted as specified below.
rd
Rationale:
As some clients may be allowed to have a Daily Limit of up to 100K, to reduce the risk rd of fraudulent transfers of large sums, BPAY, 3 Party 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
Fit Criterion:
Ensure that; BR53.1 Default Limits are set as in table below Limit Type Default Limit Pay Anyone 25K BPAY 25K Batch 0 Nominated Transfer 25K Overall Daily Limit 25K BR53.2 Ensure that client cannot increase these limits. BR53.3 Ensure that client can decrease these limits as required.
BR53.4 Ensure ABC can manage (i.e. change) these limits via Online-WebAdmin as required. Comment: Requirement changed due to gaps with core product, refer to Appendix B for original requirement
4.4. Mobile Banking Functional Requirements

Requirement 54 Rationale: Fit Criterion: Configure Online to make 'Mobile Banking' service available. Improves customer service by providing an additional channel by which client can do their banking via mobile. Ensure that client can activate mobile banking via; BR54.1 Internet Banking Activation - By signing in to internet banking and selecting the Online Mobile activation BR54.2 Mobile Phone Activation - By entering the URL of Online Mobile (as specified by ABC CSC) in the mobile phone browser and follow the self activation process using the phone.
Mobile banking logon will not require 2-Factor Authentication. Since we are only allowing payments to Trusted Payees, there is no risk in using client number and password only to login. 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 their Mobile phone after activation. Subsequent logins should not display the Terms and conditions on login after activation. This will force every mobile user to view the Terms and conditions of using mobile banking at least the first time they login. Ensure that; BR56.1 Terms and Conditions are displayed once the first time user logs onto Mobile Banking BR56.2 Subsequent logins do not display the Terms and conditions on logon
Configure Entity Manager functionality for Mobile Banking. To maintain consistency with Online Banking and thus provide better client experience. Ensure that; Client can access accounts by first selecting the relevant entity same functionality as in Online Banking
Allow Payments to Trusted Payees only. This includes payments to designated accounts defined in T24. Mobile payments should only be allowed to be made to trusted payees to minimise risk against fraudulent activities Ensure that; Payments are only to trusted payees i.e. ensure user cannot define new payees via mobile
Fit Criterion:
Activate Off-Line many to sign on the Mobile functionality so that payments from accounts with multiple signatories can be processed. Mobile does not allow over-the-shoulder authorisation. Mobile always sends out an Offline request for many-to-sign. Ensure that; 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.
Fit Criterion:
Activate email receipts when payments are made via Mobile Banking. To maintain consistency with Online Banking and thus provide better client experience Users can send email to payee and email to self if required by specifying the email addresses when processing a payment.
Requirement 61
Any payments processed via Mobile Banking will have the same cut-off times as payments made via online banking. Transactions after the cut-off time will be processed for value date of the next business day same as in existing online transactions.
Payments cut-off will be set at 16.00pm consistent with Online Banking cut-off for better client experience. 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 CutOff time applies.
Clients should not have the ability to create new Secure Messages via Mobile Banking. To reduce risk, clients will not be allowed to create new secure messages on mobile banking. BR62.1 Client cannot send a secure message via mobile BR62.2 Client can reply or delete incoming secure messages
Comment:
Requirement changed due to gaps with core product, refer to Appendix B for original requirement
Personal details display or update should not be available on Mobile Banking i.e. user cannot view their personal details on Mobile Banking This is a security control to ensure that client information is not readily available in case of fraudulent activities. Ensure client cannot view or edit personal details via Mobile Banking.
Requirement 64
Configure Mobile Profile Management as follows;

Service Payee & Biller Management P2P Payee Management Personal Details Management Configurable Font Size View Only YES NO NO YES Edit or Delete NO NO NO YES
For better security, user will only be allowed to edit Font size on their mobile. No other details can be changed. Ensure that Mobile Profile Management is configured as specified in requirement i.e. BR64.1 Allow client view only access of Payees and Billers BR64.2 Allow client to view and edit Configurable Font size on the mobile
4.5. Profile (Personal Details) Management Online Banking

Requirement 65 Rationale: Fit Criterion: Users should not be able to change/update Personal details Online same as in existing configuration. This is a security control to ensure that client information is secure and cannot be changed easily in case of fraudulent activities. 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 on online banking i.e. user cannot view or change the secret question and answer online. 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. 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 always defaults 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 to Domino as in existing functionality Finesse to T24 Interface Always interface the Mothers Maiden Name Question and Answer to the first Secret question and Answer in T24
Rationale:
Fit Criterion:
4.6. GL Requirements
Requirement 67 Rationale: Fit Criterion: The BPAY settlement account on T24 will be mapped to a separate GL JDE object. 87133.346M01.S25. For ease accounting and reconciliation of BPAY transactions Ensure that the credit posting of BPAY payments reflect in the new GL object 87133.346M01.S25 .
4.7. MIS & Mercury Interface Requirements

Detailed MIS requirements will be outstanding in this requirement (and thus are excluded from signoff) as there is a dependency on the fraud assessment outcome and getting available business resources to define reporting requirements. However, all information will be made available to MIS from which to build the required fraud reporting requirements Below are requirements for data to be included in T24 extracts into MIS to enable production of other reports. Requirement 68 Rationale: Fit Criterion: Include all the new transaction types in the MIS JDE Recon extract BPAY and 3 Party Transaction Types to be included in the JDE Recon file to enable Finance to resolve reconciliation issues. BR68.1 Replace the word Payment with Withdrawal in Transaction Descriptions when including them in MIS extracts i.e. o Transaction description BPAY Payment should be changed to BPAY Withdrawal o Transaction Description BPAY Payment Returned should be changed to BPAY Withdrawal Returned BR68.2 MIS JDE recon extract must include the following new transaction types with converted transaction descriptions as follows; AC14 Online Direct Withdrawal AC15 BPAY Withdrawal ACBD BPAY Withdrawal Returned Requirement 69 Rationale: Fit Criterion: Include new fields in MIS extracts To facilitate future reporting that will be required 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 MIS customer details extract Requirement 70 Rationale: Fit Criterion: Provide functionality for reporting on BPAY transactions To facilitate BPAY transaction reporting and analysis MIS will link to the ONLINE-WEBADMIN database for any BPAY transactions information required for reporting
rd
BPAY and 3 Party payment transactions should be included in the existing interface to the cash flow management system i.e. interface to Mercury System BPAY and 3 Party payments affect the cash flows and therefore should be included in the T24 interface to the cash flow system. Ensure that the following transactions are included in the mercury interface file; AC14 Online Direct Withdrawal AC15 BPAY Payment ACBD BPAY Payment Returned
rd
rd
4.8. User Interface Redesign for Online Internet and Mobile

Requirement 72 Rationale: Fit Criterion: Online Internet and Mobile will adhere to ABC online style guide. To adhere to ABC internet styling and keep all client facing websites consistent. Both Online Internet and Mobile look and feel will adhere to the following style guide as defined by Marketing
Online Internet menu bar will be changed to be consistent with the new ABC internet site. To adhere to ABC internet styling and keep all client facing websites consistent. The existing left hand menu items within Online will be moved to a top bar navigation.
4.9. Email Alert Statements Available Online

Requirement 74 Rationale: Fit Criterion: Require functionality to send email alert to clients when statements become available online. ABC process is that online statements are available 5 days after month end hence the need to notify clients when these become available. BR74.1 Email Notification will be sent on the 5
th
day of the proceeding month
BR74.2 Select clients who receive Online statements using the field L. PREF.DE.MTHD on the customer record If 'Online' THEN include in Mail-out list BR74.3 Extract email address to use from field L.CONT.EMAIL Recommendation: on Customer record
Recommendation is to implement this in MIS as it has the minimum development effort required to achieve the functionality.
4.10. Finesse Requirements

Requirement 75 Rationale: Provide a single view of client commitments in Finesse by displaying the full portfolio of products a client holds with ABC. 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 easy evaluation of a clients credit worthiness. Ensure that clients full portfolio with ABC including products that only exist in T24 such as Term Deposits, Notice Accounts, Private Access Accounts are displayed in Finesse on the commitments screen. Refer to Change request for further details of the requirement.
Fit Criterion
4.11. Autoforms Requirements

Requirement 76 Rationale: Review all existing correspondence to ensure new product names display correctly New Product names may be truncated on client correspondence.
Fit Criterion:
Ensure the following correspondence display product names correctly 1. Welcome Letters (Experien & PCTI) 2. Confirmation of new deposit ( 4 Letters) 3. Confirmation of Withdrawal (3 letters) 4. Confirmation of Interest Payment 5. 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 letter 11. Forthcoming Maturity of Deposit 12. Annual Tax (Experien & PCTI) 13. Monthly Account Statement
5. Online Upgrade and additional ABC Enhancements

Online upgrade will migrate to version 3.86. The upgrade will contain fixes to existing defects and pending enhancements requested by ABC. Below are the expected changes; CR-1 [IBI-407] Description: Secure Messages duplicating or not moving to Sent items when replied to. There have been instances where ONLINE-WEBADMIN User has encountered the following scenarios where the same Secure Message is viewed by two ONLINEWEBADMIN Users: It is proposed that whenever a ONLINE-WEBADMIN User encounters a Secure Message locked by another ONLINE-WEBADMIN User then the application will validate if the Secure Message has been actioned (Replied/Forwarded/Deleted) before proceeding with the action being performed. If the Secure Message is deleted while being viewed by another ONLINE-WEBADMIN user then it will be removed from the list only when the list is refreshed manually Priority: CR-2 [IBI-482] Description: Priority: CR-3 [IBI-442] Description: High Show Date & Time stamp for sent messages ABC Customer Support using ONLINE-WEBADMIN want to see the Date and Time stamp of a Secure Message that has been responded to by one of their users. High Pending transfers Screen changes 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: CR-4 [IBI-440] Description: Medium Secure Message Compose Message screen inconsistent with Compose Message screen loaded from Transaction History. In the ABC version of Online the Secure Screen there is an inconsistency in the view of 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 the pre-defined subject dropdown displayed when the Create Secure Message screen is opened from the Transaction History however, if the same screen is loaded directly from 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 Other Requests where the Subject will be user enterable. The Account dropdown will list all the accounts along with an entry for General Enquiries. Priority: Medium
CR-5 [IBI-441] Description:
Customer Limits should not apply for internal transfers between customers own accounts ABC customers using Online Online to make payments between their own accounts utilise their Customer Limits. This has caused confusion among customers who are expected 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 Overall Daily Limit. If the Funds Transfers Limits are disabled, then the Funds Transfers Limit information is not displayed. However, the Overall Daily Limit and un-utilised Overall Daily Limit are always displayed on the Transfers screen even if not updated due to Funds Transfers. Therefore, Transfers between own accounts should not utilise the Customer Limits. High (Critical) Maturity date for LD to be displayed on the Home Page 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 the Transaction History to view the Maturity Date. An Unnecessary number of clicks have to be performed for Online Users to be able to view this information. Furthermore, the data is incomplete for the deposit account details as it does not contain all information the client requires to manage their accounts via the account manager without using the advanced view. Online Online allows Online Users to access the Account Details via a single click from the Home Page. Usually, Online Users view the Account details before transacting. Online Online has introduced the feature to View Loan and Deposit Details. The Loan Details can be pulled from the Host using the getLoanAccountDetails operation of the WSDL while the Deposit Details can be pulled from the Host using the getTermDepositDetails operation in the WSDL. Medium Right align the Column Headings and Values for all number fields ABC wanted to implement the standard of Right aligning the Column Headings and Amount values for all number fields. Only the Amount fields and related headings will be Right aligned. Medium
Priority: CR-6 [IBI-466] Description:
Priority: CR7 [IBI-483] Description:
Priority:
CR8 [IBI-484] Description:
Transfers navigation changes In order to improve the usability of functions in Online Online it is required that when Online Users select Transfers on Main Navigation Menu, by default the Online User should be navigated to Transfer Money screen instead of Payments History List. High Security Questions ABC Customer Support are required to verify the identification of customer who call-in for assistance. This is done by posing Security Questions to the customer on the phone who are required to answer them. Currently, the Security Questions are stored and managed on the Host. However the following business drivers require Online to support Security Questions feature: a. New Customer must be presented Security Questions for them to answer.
Priority: CR-9 [IBI-470] Original Requirement
b. Existing Customer may be required to update their existing answers. c. ONLINE-WEBADMIN User must get a view of Security Questions along with answers so that they do not have to logon onto the Host for customer verification. New Requirement Priority: (DONOT display Security Question Online in the interim refer Requirement 66) High
CR-10 [IBI-385] Description:
Session window to be closed when session is terminated due to maximum time exceeded When user session is terminated due to maximum time exceeded, the user is navigated back to the registration login page. They have already registered and it is not logical to be returned to the registration page. The window should automatically be closed. Instead should be presented with the Online Logon screen. High Add facility to reset failed password counter during PIN reset operation ABC wish to enhance ONLINE-WEBADMIN to allow the ability to have the customers failed password counter reset to zero by the ONLINE-WEBADMIN operator. The current product behaviour is to reset this counter after a successful login, in order to ensure that when the customer logs with the correct credentials next time, they are notified accurately as to how many unsuccessful login attempts have been made on their account. This change request is to provide the ONLINE-WEBADMIN operator with the facility to reset this counter. Due to the number of failed tries already having reached 5, the customer would have only ONE single attempt to enter this new access code successfully once it was received, and if they got it wrong, their account would become blocked again to prevent further attempts. We note here that the reason the customer only has one attempt after the PIN reset is because only a successful login serves to clear the accumulated failed logins counter. We can only assume the customer typed the reset PIN unsuccessfully here with their one attempt. Try regenerating the PIN again and ensuring the customer is very careful in entered the new one and let us know the outcome Medium Changes to Transaction List View Online Users are presented with an error message immediately when they click on Account Details (ACCOUNT MANAGER). Furthermore, when Online Users select a value from the date range dropdown; the screen "refreshes" giving the impression that the search has already been executed. Following changes are required to resolve the issues: a. Default date range --Please select a date range--' so that a search is not executed and hence, no error presented. b. The value "A specified date range" should be removed from the Date Range dropdown. Each item in the date range list translated to a start & end date this calculation caused the refresh issue when a user selected a value from the list c. Online Users can execute search for a specified date range via the advanced search option By default when the Transaction List loads the Online User will be required to specify the Date Range and click on the View button, no default search on load of screen will be enabled.. High Log in again redirect parameters
Priority: CR-13 [IBI-376]
Description:
Online Banking Users may choose to login again once they log out after successful registration. This should redirect the Online Users to the Logon screen instead of the Registration screen. Medium Backspace key on the keyboard should not return the Online User to the previous page Online Banking Users who may have successfully completed the registration process and inadvertently may click on the Backspace button on the keyboard. This returns the Online User to the previous screen i.e. the login screen. Such Online Users may not be able to proceed to Online Banking any further even if they have completed the registration process successfully. The Backspace button on the keyboard should not return to the previous page. High Review and Update (Multiple) Address Details Customers may maintain multiple addresses with ABC. In addition to customers residential address, a mailing address should also be supported in Online. The mailing address should directly be updated on the Host. The Host system will generate all correspondence for the customer to be sent to the mailing address. The Personal Details tab under My Profile will support the Mailing Address. The screen shot below lists the scenario where the Residential and Mailing addresses are different. Multiple address Update should be switched off as in existing setup High
New Requirement Priority:
6. Future Considerations
Requirement A The customer create workflow for PCTI customers created direct in T24 should create the Private Current Account as the transactional account not PAA Currently the workflow creates a PAA account as a transactional account into which a client can make deposits for transfer to Term Deposit or where matured term deposit amounts are transferred to pending client instructions.
Rationale:
Requirement B
Activate SMS functionality which is triggered by user sign on i.e. when a user is logged in then an SMS Notification is sent to their mobile to alert client that they have just logged on. Enhances security against hackers who may access the system bypassing the 2factor sign in authentication
Rationale:
Requirement C
Change Secret Question and answer functionality to allow user to view and change on Online Banking. Also allow multiple questions to be captured. Changes are required to bring the 4 interfaced systems (Online, Finesse, Domino and T24) in sync with regards to Secret Questions and Answers 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
Rationale: Fit Criterion
T24 Changes: Incorporate Validation behind the Secret Question and Answer Multivalue field; o o o Multivalue field will be a dropdown list of 15 Questions First Question is Mandatory and should always be Mothers Maiden Name 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. if additional questions are captured in Finesse, ignore these questions when interfacing to Domino. Always interface the Mothers Maiden Name Question and Answer to the first Multivalue in T24 as it is mandatory in Finesse if additional questions are captured in Finesse, then map to T24 2 rd & 3 Multivalue
nd
Finesse to T24 Interface
Multivalue
Updates done in Finesse, Always Overwrite the 3 Multivalue fields in T24
Requirement D
Activate BPAY Limits functionality and allow limit to be managed by the client/user.
Rationale: Fit Criterion: Requirement E
Give clients the control to manage how they apportion the member daily limit set by ABC bank
Activate 3 Party Limits functionality and allow limit to be managed by the client/user.
rd
Rationale:
Give clients the control to manage how they apportion the member limit set by the bank Allow BPAY and 3 Party payments functionality to be available for the credit card product. 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.
rd
Requirement F
Rationale:
Appendix A New Transaction Types

The following new transaction types are required in T24; New Transaction 1 2 3 AC14 Online Direct Withdrawal AC15 BPAY Payment ACBD BPAY Payment Returned Purpose Used to process Online 3 Party Payments Used to process Online BPAY Payments Used to process Rejected BPAY Payments
rd
Full details of the fields required are as follows;
AC14 Online Direct Withdrawal

Tab/Field reference Deposit Tab Transaction Type Debit Account Debit Currency Debit Amount Effective Date Source of Instruction Target Account Name Target Account BSB Target Account Number Lodgement Reference Comment Tab Comments Charges Tab Fee Code [None] Fee Type.1 Fee Amount.1 Nostro Credit Account Credit Currency Details AC14 Online Direct Withdrawal Valid T24 customer account Default to AUD Amount to be deposited to client account Date of Processing Default to other Name of account to which funds are transferred BSB of account to which funds are transferred Account Number to which funds are transferred Lodgement Reference captured online by client Used to hold comments DR/CR Narration Online Direct Withdrawal Length Standard T24 Standard T24 Standard T24 Standard T24 Standard T24 Standard T24 Standard T24 Standard T24 Standard T24 Format
Default to ANZ Nostro Default to AUD
Statement Narrative
Line 1 Line 2 Online Direct Withdrawal Use reference captured online by client Translation of transaction type to statement Example 30/06/09 30/06/09 Online Direct Withdrawal Invoice 3399 100.00 30000.00
AC15 BPAY Payment

Tab/Field reference Deposit Tab Transaction Type Debit Account Debit Currency Debit Amount Effective Date Source of Instruction Biller Code Biller Name Customer Reference Number Comment Tab Comments Charges Tab Fee Code [None] Fee Type.1 Fee Amount.1 Nostro Credit Account Credit Currency Details AC15 BPAY Payment Valid T24 customer account Default to AUD Amount to be deposited to client account Transaction Effective Date Default to other Unique Biller Code to which funds are being sent Biller Name e.g. Telstra Reference number by Which Biller identifies Account that is being paid Used to hold comments DR/CR Narration BPAY Payment Length Standard T24 Standard T24 Standard T24 Standard T24 Standard T24 Standard T24 10 50 20 Format
Numeric Alphanumeric Alphanumeric
Default to BPAY Nostro Default to AUD
Statement Narrative
Line 1 Line 2 BPAY Payment Use Biller Name + Ref: + Customer Reference Number (CRN) Translation of transaction type to statement Example 30/06/09 30/06/09 BPAY Payment Telstra Ref: 012221227893 100.00 30000.00
ACBD BPAY Payment Returned

Tab/Field reference Deposit Tab Transaction Type Credit Account Credit Currency Credit Amount Effective Date Source of Instruction Biller Code Biller Name Customer Reference Number BPAY Settlement Date BPAY Rejection Reason Rejection Reason 2 Rejection Reason 3 Rejection Reason 4 Rejection Reason 5 Comment Tab Comments Charges Tab Fee Code [None] Fee Type.1 Fee Amount.1 Nostro Debit Account Debit Currency Details ACBD BPAY Payment Returned Valid T24 customer account Default to AUD Amount to be deposited to client account Date of Processing Default to other Unique Biller Code to which funds originally sent Biller Name e.g. Telstra Reference number by Which Biller identifies Account that is being paid Date when Payment was expected to have entered BPAY settlement 1st Reason why BPAY payment was rejected 2nd Reason why BPAY payment was rejected 3rd Reason why BPAY payment was rejected 4th Reason why BPAY payment was rejected 5th Reason why BPAY payment was rejected Used to hold comments DR/CR Narration BPAY Payment Returned Length Standard T24 Standard T24 Standard T24 Standard T24 Standard T24 Standard T24 10 50 20 Standard T24 50 50 50 50 50 Alphanumeric Alphanumeric Alphanumeric Alphanumeric Alphanumeric Format
Numeric Alphanumeric Alphanumeric
Default to BPAY Nostro Default to AUD
Statement Narrative
Line 1 Line 2 BPAY Payment Returned st Use 1 BPAY Rejection Reason Description field in FT Transaction Translation of transaction type to statement Example 30/06/09 30/06/09 BPAY Payment Returned Customer Reference Number Invalid 100.00 30000.00
Appendix B Online Gaps vs Original Requirements
Activate account SMS alert for payments of $10K and above. 10K SMS alert must apply to future/periodic payments on the day the payment is processed i.e. on due date To provide security for large amount payments. Client is notified of such payments immediately. BR47.1 An SMS notification is sent to all signatories when an online payment (3 Party 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.
rd
BR47.3 This limit will be managed by ABC and the user cannot change this limit. Current Online Behaviour In order to be notified of any pending/recurring payment (Between Own Accounts, Batch, 3rd Party 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:

ABC Response
BR47.1 BR47.2 BR47.3
No Change Request required by ABC. Activate SMS Alert functionality for Online Users as per Online Standard functionality.
Requirement 48
Activate account SMS alert for BPAY payments of $10K and above. This Limit will be managed by ABC and user cannot change this limit. 10K SMS alert must apply to future/periodic BPAY payments on the day the payment is processed. To provide security for large amounts of BPAY payments. Client is notified of such a payment immediately. BR48.1 An SMS notification is sent to all signatories when a BPAY payment of $10,000 or more is made. 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.
Current Online Behaviour
In order to be notified of any pending/recurring payment (Between Own Accounts, Batch, 3rd Party and BPAY) on an account over a certain threshold, Online Users can setup "Notification On Account Payment".
Status

ABC Response
BR48.1 BR48.2 BR48.3
No Change Request required by ABC. Activate SMS Alert functionality for Online Users as per Online Standard functionality
Requirement 49
Additional SMS services that will be configured are as shown below;

Service Balance Enquiry Transaction Enquiry (10 transactions displayed) New Mail received Alert when account has been blocked System Auto reply Pause SMS Service Delegated User Alerts Service Type Enquiry Enquiry Notification Notification Alert Configuration Alert Activate YES YES NO NO NO NO Not Configured for ABC
Rationale: Fit Criterion: Current Online Behaviour
Allow frequently requested account enquiries to be available via SMS to enhance client experience. Disallow ability for client to turn SMS service off as alerts are used to manage risk against fraudulent fund transfers. Ensure that the Balance and Transaction enquiries services are available via SMS Ensure Pause SMS service is not available to online clients Currently, the following SMS Settings are displayed to the Online User with no option to prevent these from being displayed:
Balance Enquiry Transaction History Enquiry Notification on New Arrived Mail Customer Block Alert Pause your SMS service System auto-reply SMS Delegated User Alerts
There is no option to prevent Online Users from turning-off SMS Service.
Status
ABC Response
Turn-off display of the following: o New Mail received o Alert when account has been blocked o System Auto reply o Pause SMS Service o Delegated User Alerts Configure-off the option Turn Off SMS Service.
No Change Request required by ABC. Display all SMS settings as per Online Standard Functionality BUT default Active flag as per st requirement above on 1 logon. Online User has ability to change these defaults i.e. can activate/deactivate services as per their requirement st after 1 logon.
Requirement 50
SMS menu options activated are as follows;

Service SMS Settings SMS History BPAY Alerts Quick Access Number Activate YES YES NO YES Rationale Allow View Only access to SMS services activated To view history of previous messages Out of Scope -Relates to BPAY View Allows quick account access codes to be defined. Access number will be used in Balance and Transaction enquiry
Rationale:
Fit Criterion:
Allow Quick Access Number to facilitate ease SMS enquiries. Allowing user to view SMS history reduces client enquiries made to CSC. Exclude BPAY alerts as it relates to BPAY View. Disallow user ability to change SMS settings as alerts are used to manage risk associated with fund transfers. Ensure user can: View SMS settings but cannot change 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 uses the number
1. Currently, SMS Settings can be modified by the Online user. It cannot be configured to a View-Only access: 2. BPAY Alerts is not displayed of none of the Customer Accounts possess the service code for BPAY View. 3. Quick Access Numbers can be set. 4. SMS History can be viewed by the Online user.
Status ABC Response
View-Only access to SMS Settings
No Change Request required by ABC. Disregard View Only requirement for SMS Settings.
Requirement 51
Future/periodic funds transfers SMS notifications are only sent for amounts of 10K and above Notification Future Dated Internal funds transfer Periodic Internal Funds Transfer rd Future Dated 3 Party Payments rd Periodic 3 Party Payments Future Dated BPAY payments Periodic BPAY payments Activate For amount >= 10K For amount >= 10K For amount >= 10K For amount >= 10K For amount >= 10K 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 be inundated with too many SMS which may result in them not paying enough attention to security SMS 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 certain threshold, Online Users can setup "Notification On Account Payment".
Fit Criterion:
Status
These are new requirements which should go through the Change Request process. Considered out-of-scope for the current release:

ABC Response
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.
No Change Request required by ABC. Disregard requirement to restrict user from making threshold changes. As Batch Payments functionality is not configured for ABC, I assume no notifications for future/periodic batch payments can be configured in this case. Please confirm.
BPAY payments daily Limit and 3 Party payments daily Limit will be activated and managed by ABC. 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 payments rd daily limit will be set to 25K and 3 Party 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. rd BR53.1 Ensure BPAY payments daily limit & 3 Party Payments daily limit are both set to 25K.
rd
Fit Criterion:
BR53.2 Ensure that client cannot change these limits. BR53.3 Ensure ABC can manage (i.e. change) these limits as required. Current Online Behaviour Limits can be set for BPAY payments & 3
rd
Party Payments.
Online Users can change their Daily Limits. Limits can be decreased at all times by Online Users. However, Limit Increases by Online Users can be prevented, requiring the ABC to manage the same through ONLINE-WEBADMIN.
Status ABC Response
Therefore, requirements BR53.1, BR53.2 and BR53.3 can be met through a work around. If the workaround is not acceptable then this should be treated as a new requirement which should go through the Change Request process. Considered out-of-scope for the current release: ABC accepts the workaround i.e. Limits can be decreased at all times by Online Users. However, Limit Increases by Online Users should be prevented, requiring ABC to manage all increases through ONLINE-WEBADMIN. Please set default daily limits as below. Limit Type Default Limit Pay Anyone 25K BPAY 25K Batch 0 Nominated Transfer 25K Overall Daily Limit 25K Note: For some existing clients, Overall Daily limit is >25k, this data is to be migrated as is and new limits (i.e. Pay Anyone & BPAY) set as in above table.
Clients should have the ability to send Secure Messages via Mobile Banking. Processing of secure messages involves confirming the request with the client before actioning it as such there is less risk in using this functionality on Mobile Banking. BR62.1 Client can send a secure message via mobile BR62.2 Message from Mobile is delivered to CSC inbox for secure messages
The existing behaviour is documented in IBI-519. Currently, Online Mobile allows users only to REPLY or DELETE incoming Secure Messages. These replied secure messages are delivered to ONLINE-WEBADMIN. However, Online Mobile does NOT allow users to CREATE new Secure Messages as it does in Online Online.
Status
Creating a New Secure Message from Online Mobile is a new requirement is not supported in Online Mobile. As per update in Jira IBI-519, Creating a New Secure Message is not required. Yes, functionality to create New Secure Message on Mobile not required by ABC.
ABC Response
Appendix C BPAY Business Events

Business Events BPAY and Third Party Payments
The following diagram summarises the business events that are involved in BPAY and Third Party Payments transactions.
Create third 11 party payee (add to list)
13 3
2 Ensure payment is authorised 17 7
Validate Biller Code
Generate system notifications BankLink
Make BPay payment Online Banking Client
4 Make third party payment 12
Send BPay payments to host
Send Third 14 Party Payments to host
Perform 15 standard 5 transaction checking
2 Post transactions to 6 client accounts 21 22 22 Generate BPay 8 batch 16
Enable Customer and Biller data validation
Initiate error and adjustment processing 21
T24
Generate PCS 18 batch
Bpay Via INDUE Facilitate daily financial 9 settlement
Business Events Diagram for Bpay and Third Party Payments transactions
BPAY Payments Business Events

Event Name (Actor) Make BPAY payment (Online Banking Client) Ref on diagram 1 Input / Output Input: Biller code, customer reference number, amount Event description 1. Online banking clients can make once-off or recurring payments to BPAY billers. (Recurring payments cannot be set up for all billers) 2. Clients can add billers to a list of their billers for future payments.
Output: Transaction confirmation and reference number, new biller on list of billers
Validate biller data (Online)
Input: Payment information; BPAY Biller File
For every BPAY payment, the system will validate the relevant biller data, e.g. biller, whether recurring payments are allowed, the billers authentication requirements, etc. These validation steps are performed in accordance with BPAY rules.
Output: Biller data is verified or error is generated
The biller file and validation routines are provided by BPAY and will be accessed by Online whenever a BPAY payment is initiated.
Ensure payment is authorised (Online)
Input: Account signatory requirements provided by T24 (number of signatories, customer numbers)
T24 will provide Online with the signatory requirements for each account. This includes the required number of signatories/authorisers and the list of clients that are available for authorisation. (Currently this is set to one signatory only.) Every payment in Online, including BPAY and PayAnyone payments, will require the stipulated number of authorisations, based on the account signing instructions held in T24. Refer to the Online host message specification for detailed requirements.
Output: Payment is passed to T24 after correct authorisation
Send BPAY payments to the core banking system (Online/Interface)
Input: Payment information captured in Online
All BPAY payments need to be sent to T24 for processing to clients accounts. All relevant transaction attributes need to be made available to T24 for processing, statement, and reconciliation purposes.
Output: Transaction data is delivered to T24
Perform standard transaction checking (T24)
Input: Transaction is presented to T24
Standard account and customer status, and balance checks will be performed by T24 for all BPAY and third party payment transactions. These check determine whether there are CDD or other blocks and that the available balance is sufficient for the transaction in accordance with the rules implemented for online banking. 1. All BPAY payment transactions will be debited to the clients account in T24 as selected by the client in Online. BPAY transactions will be processed to the credit of a new BPAY Nostro defined in T24. Transactions will be processed with a value date equal to the date submitted to T24 up to the transaction cut-off time (currently set to 16h30 for Online transactions). Transactions after the cut-off time will be processed for value the next business day. Cut-off times for BPAY transactions are subject to BPAY rules.
Output: Transaction is validated or error is returned
Post transactions to client accounts (T24)
Input: Transaction is validated
Output: Transaction is posted to correctly
2. 3.
4.
Event Name (Actor)
Ref on diagram
Input / Output
Event description
BPAY payment transaction processing will be facilitated through the sponsoring partner
INDUE. Cut-off time for submission of BPAY files to
INDUE is 17.00 pm
Generate system notifications (Online) 7 Input: Payment is processed The system will generate appropriate notifications (mainly by email) for predefined events, e.g. when a new electronic bill is received, when a payment was processed, etc.
Output: Email notification is generated
Generate BPAY batch (T24)
Input: BPAY transactions successfully processed in T24
Each business day, the system will generate one or more BPAY batch file(s) for submission to INDUE containing details of all BPAY transactions with a value date of the current date. The file needs to conform to the BPAY specifications.
Output: BPAY-compliant Payer Details file(s), acceptable to sponsoring partner.
ABCs sponsoring bank will be responsible for presenting ABCs transaction to the BPAY scheme and to process rejections for ABC.
Settle amounts due
Input: Daily settlement files/reports from BPAY/Sponsoring partner
The daily BPAY payments will be settled between ABC and the sponsoring partner. The settlement process will be agreed with the sponsoring partner.
Output: Adjustment of settlement accounts
Third Party Payments Business Events

Event Name (Actor) Create third party payees in Online (Online) Ref on diagram 11 Input / Output Input: Payee banking details (Name, BSB, Account number, etc) Event description Online banking clients can set up third party payees to enable payments to be made to these third parties. Clients can add payees to a list of their payees that can be used for future payments. Payees can be added/amended/deleted in Online.
Output: Payee details can be viewed on screen
Make payments to third parties (Online)
12
Input: Payee details input or selected
Online banking clients can make payments to third party payees by supplying the other partys banking details. Payees can be added to the Payee list for future payments. Once-off and recurring payments can be set up.
Output: Transaction confirmation and reference number, new payee on list of payees
Ensure payment is authorised (Online)
13
Input: Account signatory requirements provided by T24 (number of signatories, customer numbers)
T24 will provide Online with the signatory requirements for each account. This includes the required number of signatories/authorisers and the list of clients that are available for authorisation. (Currently this is set to one signatory only.) Every payments in Online, including BPAY and PayAnyone payments, will require the stipulated number of authorisations, based on the account signing instructions held in T24. Refer to the Online host message specification for detailed requirements.
Output: Payment is passed to T24 after correct authorisation
Send third party payments to host
14
Input: Payment information captured in Online
All third party payments need to be sent to T24 for processing to clients accounts. All relevant transaction attributes need to be made available to T24 for processing, statement, and reconciliation purposes. These check determine whether there are CDD or other blocks and that the available balance is sufficient for the transaction in accordance with the rules implemented for online banking.
Output: Transaction data is delivered to T24
Perform standard transaction checking (T24)
15
Input: Transaction is presented to T24
Standard account and customer status, and balance checks will be performed by T24 for all third party payment transactions.
Output: Transaction is validated or error is returned 1. Third party payment transactions will be debited to the clients account in T24 as selected by the client in Online. Third party payments to accounts held at other institutions will be credited to the existing ANZ Payment Clearing System Nostro. Existing rules regarding cut-off times for Online transactions will apply. Third party payment transactions to accounts held in T24 will be credited to the beneficiarys account directly, and will not be subject to the cut-off times and value-dating rules mentioned above.
Post transactions to client accounts (T24)
16
Input: Transaction is validated
Output: Transaction is posted to correctly
2.
3.
Generate system notifications (Online)
17
Input: Payment is processed
The system will generate appropriate notifications (mainly by email) for predefined events, e.g. when a payment was processed.
Output: Email notification is generated
Event Name (Actor) Generate PCS batch
Ref on diagram 18
Input / Output Input: Transaction successfully processed in T24
Event description All third party transactions to accounts held at other financial institutions will be included in the daily PCS file sent to ANZ following the existing processes and rules for EFT transactions to external accounts.
Output: Transaction included in PCS Outward file
BPAY errors and adjustments

Event Name (Actor) Processes BPAY rejections (T24) Ref on diagram 21 Input / Output Input: Advice of rejection transaction Event description A payment instruction that is given in error, where the error was caused by a Payer Institution; the Central BPAY Processing organisation, or a Biller Institution must be reversed on receipt of the reversal request. The intent is to unwind the effect of the transactions to be reversed.
Output: Intended transaction(s) reversed
Indue will send all rejections in a file attached to an email
Rejected (error) may be initiated from time to time through INDUE. These transactions will be provided to ABC and will need to be processed by the ABC systems.
Work in Progress
Open Process questions and issues
Ref QI 1 Category Business process Business process Description Processing of client initiated Error Corrections Processing of other Error Corrections
rd
QI 2
Handling client queries to CSC when user experiences issues making BPAY or 3 Party payments online

Sample Business Requirements1

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Sample Business Requirements1

Uploaded by

Copyright:

Available Formats

Document Version : 1.

Status:Baseline Published: -/-

ABC BANK (Australia) Ltd

Current Account And BPAY and 3rd Party Payments Processing

PRODUCT REQUIREMENTS ......................................................................................... 7

BPAY AND PAY ANYONE FUNCTIONAL REQUIREMENTS ............................... 12

ONLINE FUNCTIONAL REQUIREMENTS ................................................................ 28

WORK IN PROGRESS ............................................................................................................. 61

1.2. Version Management

1.4. Related Documents

2.2. Out of Scope

Will be covered as a future enhancement

2.3. Relevant Facts and Assumptions

2.4. Current Account Product Definition Requirements

3. BPAY and Pay Anyone Functional Requirements

BPAY Payments File

3.1 Sponsoring Institution (Indue) 3.3 Biller (e.g. Telstra, Amex)

Scope of the work

Bpay processing / settlement

1. Online Banking Client

Payment Clearing System

3.2. Functional Requirements

Requirement 7 Rationale: Fit Criterion:

Requirement 8 Rationale: Fit Criterion:

Requirement 10 Rationale: Fit Criterion:

Rationale: Fit Criterion

Requirement 19 for further details on signing instructions.

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

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

Field Length Format Description position

File Creation Date 11 to 18 File Creation Time 19 to 24 File Number 25 to 27

Filler Detail Record Record Type Payment Instruction Type

BPAY Transaction 5 to 5 Type Payer Institution Code 6 to 8

TBA (INDUE) Leave Blank

Payment Account 9 to 28 Detail

Country of Payment State of Payment

Currency Code of 35 to 37 Payment Biller Code 38 to 47

Customer 55 to 74 Reference Number

AUS (for Australia)

Biller Code field on the BPAY FT Transaction

BPAY Customer Ref field on the BPAY FT Transaction

Field Name ..Cont Payment Method

Field Length Format Description position 75 to 77 3 N

Transaction 93 to 113 21 Reference Number

Field Name ..Cont

Field Length Format Description position 21 AN

Original Reference 114 to Number 134

BPAY Settlement Date Date Payment Accepted

135 to 142 143 to 150

Time Payment Accepted

Additional Reference Code

File Release Time (Format HHMMSS)

T24 FT Number of the BPAY Transaction

Field Name ..Cont Error Correction Reason

Field Length Format Description position 9 N

The number of Reversal Instructions in the file.

Always zero (No Reversal records expected)

The amount of Reversal Instructions in the file.

Always zero (No Reversal records expected)

Sum Total of Amount field on the BPAY FT of all Transactions in file

3.4. BPAY File Processing in T24

3.5. BPAY Acknowledgement & Rejections File Processing in T24

Requirement 25 Rationale: Fit Criterion: