Академический Документы
Профессиональный Документы
Культура Документы
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
Sample-Business-Requirements.docx Page 2 of 61
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.
3.
3.1. 3.2. 3.3. 3.4. 3.5.
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.
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
Sample-Business-Requirements.docx Page 3 of 61
Sample-Business-Requirements.docx Page 4 of 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.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
Sample-Business-Requirements.docx Page 5 of 61
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
Sample-Business-Requirements.docx Page 6 of 61
2. Product Requirements
A Current Account is an on call transactional account paying a variable rate of interest. Current Accounts provide the client with transactional capability through the online channel specifically allowing BPAY and third 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. BPAY View via Online functionality o Functionality allows clients to view their BPAY bills online through Online
Sample-Business-Requirements.docx Page 7 of 61
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
Sample-Business-Requirements.docx Page 8 of 61
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.
Assumption 3 Assumption 4
Assumption 5 Assumption 6
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
Sample-Business-Requirements.docx Page 9 of 61
Assumption 8 Assumption 9
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
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:
Requirement 3 Rationale:
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
Sample-Business-Requirements.docx Page 10 of 61
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.
Sample-Business-Requirements.docx Page 11 of 61
Bpay Payment
3.2 Bpay
Transact
Bpay & PayAnyone Transaction - submit PCS Payments file (3rd Party Payments) 2.2 T24
2.1 BankLink
Acknowledge / Reject
System processing
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.
Sample-Business-Requirements.docx Page 12 of 61
Maintain third party payee lists created by clients. Check and manage daily transaction limits.
Online will present transactions to T24 for validation and processing on payment due date. T24 will perform client, account, transaction and balance checks in line with its standard transaction processing rules. The system will generate a daily BPAY Payment Details file to enable billers to update 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.
Rationale:
Fit Criterion:
Requirement 6 Rationale:
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.
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
Sample-Business-Requirements.docx Page 13 of 61
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
Requirement 9 Rationale:
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
Sample-Business-Requirements.docx Page 14 of 61
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:
Sample-Business-Requirements.docx Page 15 of 61
Fit Criterion:
BR14.1 BPAY payments will be listed on a separate withdrawal report BR14.2 The report will be the same format as existing PCS withdrawal report 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
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:
Sample-Business-Requirements.docx Page 16 of 61
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.
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:
Sample-Business-Requirements.docx Page 17 of 61
Requirement 21 Rationale:
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:
Sample-Business-Requirements.docx Page 18 of 61
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
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
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)
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.
Sample-Business-Requirements.docx Page 19 of 61
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
3 20
29 to 31
32 to 34
10
Service Code
48 to 54
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.
Leave Blank
AUD
Zero
Detail Record
Sample-Business-Requirements.docx Page 20 of 61
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
Detail Record
Sample-Business-Requirements.docx Page 21 of 61
Value
T24 Field
151 to 156
Payer Name
40
OA
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)
Detail Record
Sample-Business-Requirements.docx Page 22 of 61
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
Sample-Business-Requirements.docx Page 23 of 61
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
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)
15
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
179
Sample-Business-Requirements.docx Page 24 of 61
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.
Requirement 24 Rationale:
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
Sample-Business-Requirements.docx Page 25 of 61
Indue, emails from Indue will be forwarded to the operations team. Fit Criterion: Ensure an operations team distribution email address is created Ensure that the confirmation emails from Indue are received by each operations 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
Requirement 27 Rationale:
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.
Sample-Business-Requirements.docx Page 26 of 61
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.
Sample-Business-Requirements.docx Page 27 of 61
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
New
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
SMS
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
Sample-Business-Requirements.docx Page 28 of 61
Fit Criterion:
Requirement 41 Rationale:
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:
Requirement 42 Rationale:
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:
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
Requirement 44 Rationale:
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:
Sample-Business-Requirements.docx Page 29 of 61
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
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.
Sample-Business-Requirements.docx Page 30 of 61
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
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
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:
Sample-Business-Requirements.docx Page 31 of 61
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:
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
Sample-Business-Requirements.docx Page 32 of 61
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
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
Sample-Business-Requirements.docx Page 33 of 61
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
Requirement 58 Rationale:
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:
Requirement 59 Rationale:
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.
Sample-Business-Requirements.docx Page 34 of 61
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
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
Sample-Business-Requirements.docx Page 35 of 61
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 .
Sample-Business-Requirements.docx Page 36 of 61
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
Sample-Business-Requirements.docx Page 37 of 61
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.
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.
Sample-Business-Requirements.docx Page 38 of 61
Fit Criterion
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
Sample-Business-Requirements.docx Page 39 of 61
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
Sample-Business-Requirements.docx Page 40 of 61
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:
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.
Sample-Business-Requirements.docx Page 41 of 61
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
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
Sample-Business-Requirements.docx Page 42 of 61
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
Sample-Business-Requirements.docx Page 43 of 61
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
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
Multivalue
Sample-Business-Requirements.docx Page 44 of 61
Requirement D
Activate BPAY Limits functionality and allow limit to be managed by the client/user.
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:
Sample-Business-Requirements.docx Page 45 of 61
Sample-Business-Requirements.docx Page 46 of 61
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
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
Sample-Business-Requirements.docx Page 47 of 61
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
Sample-Business-Requirements.docx Page 48 of 61
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
No Change Request required by ABC. Activate SMS Alert functionality for Online Users as per Online Standard functionality.
Sample-Business-Requirements.docx Page 49 of 61
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.
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
No Change Request required by ABC. Activate SMS Alert functionality for Online Users as per Online Standard functionality
Sample-Business-Requirements.docx Page 50 of 61
Requirement 49
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
Status
This is a new requirement which should go through the Change Request process. Considered out-of-scope for the current release:
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.
Sample-Business-Requirements.docx Page 51 of 61
Requirement 50
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.
This is a new requirement which should go through the Change Request process. Considered out-of-scope for the current release:
No Change Request required by ABC. Disregard View Only requirement for SMS Settings.
Sample-Business-Requirements.docx Page 52 of 61
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:
The SMS notification has to be setup by the Online User. The threshold can be set to any value by the Online User. FI cannot define the threshold. The SMS notification is generated and sent only to the Online User setting up the payment.
Status
These are new requirements which should go through the Change Request process. Considered out-of-scope for the 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.
Requirement 53 Rationale:
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.
Sample-Business-Requirements.docx Page 53 of 61
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.
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.
Sample-Business-Requirements.docx Page 54 of 61
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
Sample-Business-Requirements.docx Page 55 of 61
13 3
T24
Business Events Diagram for Bpay and Third Party Payments transactions
Sample-Business-Requirements.docx Page 56 of 61
Output: Transaction confirmation and reference number, new biller on list of billers
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.
The biller file and validation routines are provided by BPAY and will be accessed by Online whenever a BPAY payment is initiated.
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.
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.
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.
2. 3.
4.
Sample-Business-Requirements.docx Page 57 of 61
Ref on diagram
Input / Output
Event description
BPAY payment transaction processing will be facilitated through the sponsoring partner
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.
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.
ABCs sponsoring bank will be responsible for presenting ABCs transaction to the BPAY scheme and to process rejections for ABC.
The daily BPAY payments will be settled between ABC and the sponsoring partner. The settlement process will be agreed with the sponsoring partner.
Sample-Business-Requirements.docx Page 58 of 61
12
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
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.
14
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.
15
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.
16
2.
3.
17
The system will generate appropriate notifications (mainly by email) for predefined events, e.g. when a payment was processed.
Sample-Business-Requirements.docx Page 59 of 61
Ref on diagram 18
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.
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.
Sample-Business-Requirements.docx Page 60 of 61
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-Requirements.docx Page 61 of 61