Becs Procedures
Becs Procedures
Version E053
PROCEDURES
for
PROCEDURES
FOR
BULK ELECTRONIC CLEARING SYSTEM FRAMEWORK
(CS2)
INDEX
Item
1.
Page Number
PRELIMINARY
1.1
1.1
1.2
1.7
1.9
1.10
1.11
1.1
1.10
1.12
1.12
1.12
1.12
Definitions
Interpretation
Inconsistency with Constitution or Regulations
Governing Law
Copyright
Application of Procedures
2.
EFFECT
2.1
3.
3.1
3.1
3.2
3.1
3.1
4.
4.1
4.1
4.1A
4.2
4.5
4.6
4.1
4.1
4.1
4.2
4.2
4.7
4.8
4.9
4.10
4.11
4.12
4.13
4.14
4.15
4.16
4.17
4.18
4.20
4.21
5.
Conduct of Clearings
Amendment
4.3
4.3
4.4
4.4
5.1
5.1
5.2
5.3
5.7
5.8
5.9
5.1
5.1
5.1
5.2
5.2
5.3
5.11
5.12
5.14
5.15
5.16
5.16A
5.16B
5.17
5.18
5.19
5.20
5.21
5.22
6.
5.4
5.4
Refusals
Direct Entry Returned or Refused - Voucher Specifications
Notification to User of Transfer or Change to Customer's Account
Transitional
6.1
6.1
6.2
6.5
6.7
6.7B
6.7G
6.8
6.9
6.10
6.11
6.1
6.1
6.1
6.2
6.3
6.4
6.5
6.6
6.6
6.12
6.13
7.
Trace Record
User Identification Numbers
Clauses 5.14 to 5.22 are Confidential
Recall Requests
Recall Requests Processed via a Bureau
Return Requests
Reversals
Return Requests - Mistaken Payments
Unposted Items
6.7
6.8
6.8
7.1
7.1
7.2
7.3A
7.4A
7.5
7.6
7.7
7.8
7.1
7.1
7.1
7.2
7.3
7.4
7.5
7.9
7.10
7.11
7.12
*
*
7.12A
7.12E
7.13
*
7.14
7.15
ii
7.5
7.8
7.8
7.11
7.13
Deleted
Deleted
7.14
7.15
7.16
Deleted
7.17
7.17
8.
9.
10.
11.
12.
13.
8.1
8.1
8.2
8.3
8.4
8.5
8.1
8.1
8.2
8.2
8.2
SETTLEMENT
9.1
9.1
9.2
9.2A
9.2B
9.2C
9.2D
9.2E
9.2F
9.2G
9.2H
9.2I
9.3
9.4
9.5
9.1
9.1
9.2
9.2
9.2
9.2
9.2
9.3
9.3
9.4
9.4
9.5
9.4
9.5
Date of Settlement
Method of Settlement
Obligation to Submit File Settlement Instructions
Rejection of File Settlement Instructions
Obligation to Monitor Accruing Settlement Obligation
Recalling File Settlement Instructions
Disputed Amounts
Interest Adjustments
Settlement of File Settlement Instructions
Late Submission of File Settlement Instruction
Settlement of file Settlement Instructions at End of Day
Settlement Contact Points (Confidential)
Variations to Normal Settlement
RITS Low Value Settlement Service
CONTINGENCY PROCEDURES
10.1
10.1
10.2
10.3
10.4
10.5
10.6
10.7
10.8
10.9
10.10
10.11
10.12
10.13
10.1
10.1
Deleted
10.2
10.2
10.2
Deleted
10.3
10.4
10.4
10.4
10.5
10.6
Responsibilities
Options
Magnetic Tape Handling (Confidential)
Physical Medium Exchange Standards
Read/Write Format Standards For Physical Medium
Structure of File
Blocking Factor
Contact Points (Confidential)
Contingency Exchange Arrangements
Bilateral Testing of Contingency Exchange Arrangements
Contingency Procedures Testing Certificate
Standards for Email File Exchange and Security
Email File Exchange Contacts Database
11.1
11.1
11.1
Fraudulent Items
DE FILE SPECIFICATIONS
12.1
12.1
12.3
12.4
12.5
12.6
12.1
12.1
12.2
12.3
12.3
Overview
Character Bit Structure
Structure of File
Record Format
Publication of DE User Item File Specifications
13.1
iii
14.
13.7
Web Browser BUDS User FI Interface
SUMMARY FILE SPECIFICATION
14.1
14.1
14.3
14.4
14.5
14.6
14.1
14.1
14.1
14.1
14.2
Overview
Character BIT Structure
Structure of Summary File
Record Format
Publication of Summary File Specification
APPENDIX A
DOCUMENTS
A1
A1.1
A2
A2.1
A3
A3.1
A4
A4.1
A5
Deleted
A6
Deleted
A7
Form PD-C
A7.1
A8
A8.1
A9
Deleted
A10
A10.1
A11
Linking Indemnity
Deleted
A12
Exchange Summary
Deleted
A13
Deleted
A14
Deleted
A15
Deleted
A16
A16.1
A17
A17.1
A18
A18.1
A19
A19.1
A20
A20.1
A21
A21.1
A22
A22.1
iv
A23
A23.1
A24
A24.1
A25
A25.1
A26
A26.1
A27
A27.1
A28
A28.1
A29
A29.1
A30.1
A30
APPENDIX B
B1
Operational Contacts
B1.1
B2
B2.1
B3
Processing Centre
B3.1
B4
TNA Excesses
B4.1
B5
Electronic Return/Refusal
B5.1
B6
Settlement Contact
B6.1
B7
B7.1
B8
Trace Requests
B8.1
B9
B9.1
B10
B10.1
B11
B11.1
B12
B12.1
B13
B13.1
B14
B14.1
APPENDIX C
C1
C1.1
C2
C2.1
C3
C3.1
C4
C5
C4.1
C5.1
C6
C6.1
C7
C7.1
APPENDIX D
SPECIFIED LOCATIONS
Deleted
APPENDIX E
Deleted
APPENDIX F
Table 1A:
F.1
Table 1B:
F.2
Table 2:
F.4
APPENDIX G
G1
G1.1
G2
G2.1
APPENDIX H
APPENDIX I
I1
Executive Summary
I1.2
I2
I2.1
I3
Communications
I3.1
I4
I4.1
I5
Disabling Events
I5.1
APPENDIX J
J1
J1.1
J2
J2.1
APPENDIX K
K1.1
APPENDIX L
L1.1
APPENDIX M
M1
M1.1
M2
M2.1
M2.2
M3
M3.1
vi
Deleted
Preliminary
PROCEDURES
for
BULK ELECTRONIC CLEARING SYSTEM FRAMEWORK
(CS2)
PART 1
PRELIMINARY
Definitions
1.1
The following words have these meanings in these Procedures unless the contrary intention
appears.
Account Details means the BSB number and/or the account number.
Inserted
effective 20/03/13
APCA Mail Box means the facility established by APCA for the purposes of facilitating the
exchange of requests for Regular Payments Lists, Regular Payments Lists and account switching
notices between Framework Participants.
Inserted
effective 01/07/12
the purpose of co-ordinating, facilitating and protecting the conduct and settlement of
exchanges of Items between Framework Participants and all aspects of the related
clearing cycle; and
(b)
Bureau means a person which either creates a File on behalf of a single User and lodges it
with a Lodgement FI or creates Multi-User Files on behalf of more than one User and lodges
these with a Lodgement FI on behalf of those Users.
Preliminary
Chief Executive Officer means the person appointed as a chief executive officer of the
Company under Article 7.13 and a reference in these Procedures to the Chief Executive Officer
includes a reference to a person nominated by the chief executive officer to be responsible for
the matter referred to in that reference.
Claim Request means a document in the form of Appendix A16.
Amended
effective 21/05/12
Company means Australian Payments Clearing Association Limited (ABN 12 055 136 519).
Confirmation of Recall means a document in the form of Appendix A1.
Contingency means any Disabling Event and any other event or circumstance specified by
the Management Committee for the purposes of Regulation 9.1.
Inserted
effective 28/10/96
Contingency Exchange Testing Schedule means the schedule published by the Company
and approved by the Management Committee as required but certainly at a minimum of every
four years, showing testing partners for all BECS Tier 1 Framework Participants for mandatory
testing, each calendar half year, of contingency exchange arrangements pursuant to clause 10.10
of these Procedures. The schedule will be published on the Companys extranet.
Last amended
effective 1/11/08
Contingency File Exchange Form means a document, substantially in the form of Appendix
M1, used by a sending or Disabled Tier 1 Framework Participant to advise a receiving Tier 1
Framework Participant that a pending/expected file exchange will take place using a bilaterally
agreed contingency exchange arrangement (as set out in Appendix L).
Inserted
effective 30/6/03
Contingency Procedures means the procedures in Part 10 and in any contingency plans
formulated and approved by the Management Committee under Regulation 9.1.
Inserted
effective 28/10/96
Inserted
effective 21/05/12
Credit Items includes all credit payment instructions contained in a File, addressed to a
Ledger FI, except as may be specifically excluded by the Regulations or these Procedures.
Credit User means a person who issues Credit Items through a User FI for distribution to a
Ledger FI. Note: A person does not become a Credit User by reason only of issuing Reversing
Items.
Last amended
effective 4/8/2000
into whose account(s) a Users Record Type 1 Credit Items are credited; or
(b)
from whose account(s) a Users Record Type 1 Debit Items are debited; or
(c)
Customer Claim means a document in such form as the relevant Ledger FI may approve and,
at a minimum, satisfying the requirements of clause 7.8(a)(iii).
Last amended
effective 11/6/08
Preliminary
Daily Summary Report means a report containing any additions, deletions or other changes
to Users' details, an example of which is set out in Appendix A3.
DDR means a Direct Debit Request.
Inserted
effective 31/3/2000
DDR Compliance Date means the date approved and published by the Management
Committee on and from which Debit Users will be required to ensure that all debit authorities
for BECS given by Customers are Direct Debit Requests.
Inserted
effective 31/3/2000
DDR Implementation Date means the date approved and published by the Management
Committee for the introduction of Direct Debit Requests.
Inserted
Effective 31/3/2000
DDR Service Agreement means a Debit Users binding agreement given for the benefit of a
Customer as to the basis on which it will provide direct debit services to that Customer through
BECS, in such form as the relevant Sponsor may approve, which if given in writing is
substantially in the form of Appendix A28 and, at a minimum, satisfying the requirements of
clause 7.11.
DDR Transitional Period means the period commencing on the DDR Implementation Date
and ending on the day immediately preceding the DDR Compliance Date.
Last amended
effective 23/12/09
Inserted
effective 31/3/2000
Debit Items includes all debit payment instructions, contained in a File, addressed to a Ledger
FI, except as may be specifically excluded by the Regulations or these Procedures.
Debit User means a person who issues Debit Items through a User FI for distribution to a
Ledger FI. Note: A person does not become a Debit User by reason only of issuing Reversing
Items.
Last amended
effective 4/8/2000
Debit User/Credit User - Change of Name or Other Details Advice means an advice of
supplementary change of name or other details for a Debit User or Credit User in the form of
Appendix A17.
Last amended
effective 24/01/12
Inserted
effective 14/12/95
Inserted
effective 25/11/13
DE File Reversal Specifications means the technical specifications set out in Appendix C5
for Reversal Files.
Inserted
effective 4/8/2000
Last amended
effective 4/8/2000
DE File User Item Specifications means the technical specifications set out in Appendix C1
for Record Type 1 Credit Items and Debit Items issued by Users.
Inserted
effective 28/10/96
DES Advice means a Direct Entry System Advice in the form of Appendix A4.
Detail Record in relation to any Item, means the record on the relevant File which contains
information on that Item. (See Appendices C1, C2, C3 and C5).
Last amended
effective 4/8/2000
Preliminary
DE File Refusal Specifications means the technical specifications set out in Appendix C3 for
Refusal Files.
Inserted
effective 28/10/96
DE File Return Specifications means the technical specifications set out in Appendix C2 for
Return Files.
Inserted
effective 28/10/96
Direct Debit Cancellation Request means a document in the form of Appendix A21.
Amended
effective 01/07/12
Direct Debit Request means an authority and request to debit amounts to a specified account
of a Customer with the Ledger FI satisfying the requirements of clause 7.4 and which, if given in
writing, is substantially in the form of Appendix A27.
Last amended
effective 23/12/09
Last amended
effective 4/8/2000
(b)
(c)
which affects, or may affect, the ability of any Framework Participant to participate to the
normal and usual extent in exchanges of Items (including Record Type 1 Items issued by any
User, Returned Items, Refused Items and Reversing Items).
Disabled Framework Participant means a Framework Participant experiencing a disabling
event which affects their ability to participate in the normal (primary) exchange and/or
processing of data file(s) in the Framework.
Inserted effective
23/09/02
ePayments Code means the electronic payments Code issued by ASIC in September 2011,
including any substitute document howsoever entitled.
Inserted
effective 20/03/13
Error of Magnitude is an error (or a series of errors on the one exchange) of or exceeding $2
million.
Last amended
effective 12/7/09
Evening Settlement Session has the meaning given in the RITS Regulations.
Inserted
effective 25/11/13
Exchange Settlement Funds has the meaning given in the RITS Regulations.
Inserted
effective 21/05/12
Deleted
effective 21/05/12
Deleted
effective 21/05/12
Deleted
effective 21/05/12
Preliminary
File means one or more Items in an electronic format (and, for the avoidance of doubt,
includes Files containing Record Type 1 Items issued by any User, Return Files, Refusal Files
and Reversal Files). (See Part 12 and Appendices C1, C2, C3 and C5 for required
specifications).
Last amended
effective 4/8/2000
File Recall Instruction means a file in the format prescribed by the Reserve Bank of
Australia and complying with the specifications for the RITS Low Value Settlement Service
which can be accessed via a link on the Companys extranet.
Inserted
effective 21/05/12
File Recall Response means a response to a File Recall Instruction, generated by the RITS
Low Value Settlement Service.
Inserted
effective 21/05/12
File Settlement Advice means an advice in relation to a File Settlement Instruction, generated
by the RITS Low Value Settlement Service.
Inserted
effective 21/05/12
File Settlement Instruction means a file in the format prescribed by the Reserve Bank of
Australia and complying with the specifications for the RITS Low Value Settlement Service
which can be accessed via a link on the Companys extranet.
Inserted
effective 21/05/12
File Settlement Response means a response to a File Settlement Instruction, generated by the
RITS Low Value Settlement Service.
Inserted
effective 21/05/12
Inserted
effective 01/07/14
Framework Participant means a body corporate which in accordance with the Regulations is
a participant in BECS.
Amended
Effective 01/07/14
Form PD-C means a request and authority so termed made in writing by a Customer before
the DDR Compliance Date to and in favour of a Ledger FI, substantially in the form of
Appendix A7.
Last amended
effective 31/3/2000
Last amended
effective 1/04/02
Last amended
effective 1/04/02
(a)
(ii) some other statutory body wholly owned or controlled, directly or indirectly, by the
Commonwealth Government or a State Government and approved by the
Management Committee, and
(b)
Guidelines for Establishing Direct Debit Requests over the Internet means the document
entitled as such issued and varied by the Company from time to time including any substitute
document howsoever entitled.
Inserted effective
31/03/04
Guidelines for Mistaken Payments means the document entitled as such and issued and
varied by the Company from time to time including any substitute document howsoever entitled.
Inserted
effective 20/03/13
Preliminary
Incoming FI means a Ledger FI which makes a request under clause 6.7B or clause 7.12A.
Inserted effective
01/07/12
Inter-bank Settlement Interest Rate means the interest rate determined in accordance with
clause 9.2F.
Amended
effective 21/05/12
Inserted effective
13/06/01
Items means Credit Items and Debit Items (and, for the avoidance of doubt, includes Record
Type 1 Items issued by any User, Returned Items, Refused Items and Reversing Items).
Last amended
effective 4/8/2000
Ledger FI means in relation to an Item, the Framework Participant or Appointor to which the
Item is addressed.
Linking Indemnity: Deleted effective 31/3/2000.
Lodgement FI means a Framework Participant or Appointor with which Files are lodged.
LVSS means the RITS Low Value Settlement Service.
Inserted
effective 21/05/12
LVSS BCP Arrangements means the contingency plan and associated documents published
by the Reserve Bank of Australia for the purposes of the RITS Low Value Settlement Service,
and which can be accessed via a link on the Companys extranet.
Inserted
effective 21/05/12
LVSS Contact means the person nominated by a Tier 1 Framework Participant as its primary
contact for LVSS enquiries, as listed in Appendix B.
Inserted
effective 21/05/12
Inserted
effective 28/10/96
Inserted
effective 20/03/13
Morning Settlement Session has the meaning given in the RITS Regulations.
Amended
effective 21/05/12
Multilateral Intraday Settlement means the multilateral net settlement of obligations which
is scheduled to occur in RITS five times each day that RITS is open, between approximately:
Inserted
effective 25/11/13
(a)
(b)
(c)
(d)
(e)
Amended effective
25/11/13
Preliminary
National Public Holiday means any day which is gazetted as a public holiday in each State
and Territory in Australia.
Inserted effective
17/01/11
Nine AM (9am) Settlement means the multilateral net settlement of obligations arising from
previous days clearings of low value payments which occurs in RITS at approximately 9am
each business day that RITS is open.
Inserted
effective 21/05/12
Notice of Redirection of a Direct Entry Item means a notice in the form set out in Appendix
A10.
Notice of Unapplied Credit Item (Superannuation) means a document substantially in the
form of Appendix A26.
9.00am Funds: Deleted effective 21/05/12.
Notice of Variation of Account Details means a direction to a Debit User or Credit User to
change the account to be debited or credited substantially in the form of Appendix A24.
Deleted
effective 21/05/12
Inserted effective
01/07/12
Note: the Notice of Variation of Account Details is designed to replace previous version of
Appendix A24 (Switch of Financial Institution and Account Details). By signing a single Notice
of Variation of Account Details, the customer authorises:
1.
2.
to notify those Debit Users and Credit Users, with whom the customer has direct debit
arrangements and credit arrangements, via the relevant Sponsors and User FIs, of the change to
the customers financial institution and account details.
Official Government File Exchange Time means the times referred to as such in clause 4.2.
Last amended
effective 1/04/02
Official Exchange Times means the times referred to as such in clause 4.2.
Inserted
effective 28/10/96
Inserted
effective 21/05/12
Outgoing FI means a Ledger FI which receives a request to provide a Regular Payments List
under clause 6.7B or clause 7.12A.
Inserted effective
01/07/12
Deleted effective
01/07/14
PD Day means in relation to a File the day on which that File is to be processed, following
exchange of the File by the Lodgement FI, and in relation to an Item, the day on which the File
containing that Item is to be processed following exchange of the File by the Lodgement FI.
Last amended
effective 18/01/02
PDN means a Processing Difficulty Notification form, substantially in the form of Appendix
J, used by a Framework Participant to notify APCA of a Disabling Event in accordance with
paragraph 3.3 of Appendix I.
Inserted effective
23/09/02
Amended effective
01/07/12
Preliminary
Recall means a recall of the entire amount of an Item or File prior to the exchange of the Item
or File.
Receiving Dataset means, in relation to the transmission of a File, the receiving destination
details for that File, nominated by the Ledger FI to which that File is addressed.
Inserted
effective 18/01/02
Receiving Member in relation to any Item (including Record Type 1 Items issued by any
User, Returned Items and Refused Items), means the Framework Participant (whether or not it
is the institution to which that Item is addressed) to which such Item is in fact delivered by the
Sending Member.
Last amended
effective 28/10/96
Record Type has the same meaning as in clause 12.2 and Appendices C1, C2, C3 and C5,
and clause 14.2 and Appendix C6. Any reference to any particular Record Type means that
particular Record Type specified in clause 12.2 and, as applicable, the DE File User Item
Specifications (Appendix C1), DE File Return Specifications (Appendix C2), DE File Refusal
Specifications (Appendix C3) and DE File Reversal Specifications (Appendix C5), and in clause
14.2 and, as applicable, the Summary File Specification (Appendix C6).
Last amended
effective 28/10/05
Inserted
effected 28/10/96
Refusal Codes means the codes specified as such in clause 4.8. Any reference to a particular
Refusal Code means that particular Refusal Code specified in clause 4.8.
Inserted
effective 28/10/96
Refusal File means a File containing Refused Items. (See Part 12 and Appendix C3 for
required Specifications).
Inserted
effective 28/10/96
Refused Item means, in relation to any Returned Item, an Item which is used to effect Refusal
(using Record Type 3) by the Receiving Member of that Returned Item.
Inserted
effective 28/10/96
Regular Payments List means a list of recurring Debit Items and Credit Items applied to a
Personal Account within the last 13 months, substantially in the form of Appendix A25.
Amended
effective 01/07/12
Last amended
effective 24/11/03
Return File means a File containing Returned Items (See Part 12 and Appendix C2 for
required specifications).
Inserted
effective 25/5/07
Returned Item means, in relation to any Record Type 1 Item issued by a User, an Item which
is used to effect return (using Record Type 2) by the Receiving Member of that Users Item.
Inserted
effective 4/8/2000
Inserted
effective 28/10/96
Reversal means the reversal, in accordance with clause 5.16A, of a Record Type 1 Item,
issued by a User, Bureau or Sending Member that has been sent in error.
Last amended
effective 25/5/07
Reversal File means a File containing Reversing Items (see Part 12 and Appendix C5 for
required specifications).
Inserted
effective 25/5/07
Reversing FI means a Framework Participant that initiates a Reversal File. Note: The
Reversing FI ID Number of that Framework Participant appears in the Reversal File.
Inserted
effective 4/8/2000
Inserted
effective 4/8/2000
Inserted
effective 4/8/2000
Preliminary
to submit File Settlement Instructions and associated File Recall Instructions; and
(b)
if it so elects, to receive File Settlement Advices, File Settlement Responses and File
Recall Responses.
Inserted
effective 21/05/12
RITS Regulations means the regulations for RITS published by the Reserve Bank of
Australia.
Inserted
effective 21/05/12
Sending Member in relation to any Item (including Record Type 1 Items issued by any User,
Returned Items and Refused Items), means the Framework Participant which delivers that Item
to a Receiving Member.
Last amended
effective 28/10/96
Deleted
effective 21/05/12
Sponsor means a Framework Participant which sponsors a Debit User pursuant to Part 7.
Summary File means a File containing summary information relating to a File or
Government File (see Part 14 and Appendix C6 for required specification).
Inserted
effective 28/10/05
Summary File Specification means the technical specification set out in Appendix C6 for a
Summary File.
Inserted
effective 28/10/05
Superannuation Entity has meaning given to that term in the Superannuation Industry
(Supervision) Act 1993.
Switching Customer means a person who has an account with the Outgoing FI and has
opened a new account with the Incoming FI.
Inserted effective
01/07/12
TNA means an authority entitled "Transaction Negotiation Authority" given by a TNA Issuer
to a Lodgement FI to process a File containing a User's Credit Items, the total of which do not
exceed a specified amount during a specified frequency in the form set out in Appendix A8.
Last amended
effective 14/12/95
TNA Issuer in relation to a TNA in support of a Credit User's File means the relevant User FI
or, to the extent that the Credit User's funding account is held with a Framework Participant or
Appointor which is not the User FI, that Framework Participant or Appointor.
Inserted
effective 14/12/95
Trace Record means the BSB Number and account number to which an Item (including any
Record Type 1 Item issued by any User, any Returned Item, any Refused Item and any
Reversing Item) must be returned if it cannot be applied. A Trace Record must be the Users
own account or an account which the User has authority to operate and/or use as a Trace Record.
The Trace Record is to be included in character positions 81 to 96 inclusive of a Detail Record
(refer clause 5.11 and Appendix C1).
Last amended
effective 27/07/07
(Note: In many cases the Trace Record is also used to satisfy the requirements of the AntiMoney Laundering and Counter-Terrorism Financing Act 2006 (Cth) concerning the inclusion
of Tracing Information in electronic funds transfer instructions. Please refer to Part 5 of the Act
for details.)
Preliminary
Trace Record Institution in relation to any Item (including Record Type 1 Items issued by
any User, Returned Items, Refused Items and Reversing Items) means the financial institution
specified (by reference to its BSB Number) in the Trace Record for that Item.
Last amended
effective 4/8/2000
(b)
in writing;
(c)
(d)
signed by the Switching Customer and each person whose signature is required to
operate the particular Personal Account;
(e)
specifying account information which corresponds with the Outgoing FIs account
identification information for that Switching Customer, including BSB and account
number and the names of persons authorised to operate the account; and
(f)
Inserted effective
01/07/12
Interpretation
1.2
(b)
(c)
(d)
a reference to a statute, code or the Corporations Law (or to a provision of a statute, code
or the Corporations Law) means the statute, the code, the Corporations Law or the
provision as modified or amended and in operation for the time being, or any statute,
code or provision enacted in lieu thereof and includes any regulation or rule for the time
being in force under the statute, the code, the Corporations Law or the provision;
(e)
a requirement to:
Last amended
effective 31/3/2000
Last amended
effective 31/3/2000
Inserted
effective 31/3/2000
(i)
(ii)
retain a document; or
(iii)
(f)
(g)
(h)
Preliminary
Last amended
effective 31/03/04
Last amended
effective 10/09/2001
(i)
the person to whom the signature is required to be given consents to the signature
being given by way of that method (The requirement in this clause 1.2(f)(i) does
not apply if a reproduction of the Customers signature appears in the electronic
communication); and
Last amended
effective 1/11/08
(ii)
either:
Last amended
effective 31/03/04
(A)
having regard to all the relevant circumstances at the time the method was
used, the method was as reliable as reasonably appropriate for the
purposes for which the information was communicated; or
Last amended
effective 31/03/04
(B)
Last amended
effective 31/03/04
(ii)
a Form PD-C or a Direct Debit Request referable to a third-party Debit User from
which the relevant Debit User has acquired a business involving direct debit
arrangements under BECS, which continued after that acquisition for the benefit
of the relevant Debit User; and
a reference to a Debit User making payment otherwise than in accordance with a Direct
Debit Request or failing to make payment in accordance with a Direct Debit Request is to
be taken to include any failure on the part of the Debit User to debit in accordance with
the debit arrangements set out in the Debit User's DDR Service Agreement applicable to
it at the relevant time.
1.3
Words defined in the Corporations Law have, unless the contrary intention appears, the same
meaning in these Procedures.
1.4
Words defined in the Regulations have, unless the contrary intention appears, the same meaning
in these Procedures.
1.5
These Procedures have been determined by the Management Committee and take effect on the
date specified by the Chief Executive Officer pursuant to Regulation 1.2.
1.6
Headings are inserted for convenience and do not affect the interpretation of these Procedures.
Inserted
effective 31/3/2000
Inserted
effective 31/3/2000
Preliminary
1.8
Governing Law
1.9
These Procedures are to be interpreted in accordance with the same laws which govern the
interpretation of the Articles.
Copyright
1.10
Application of Procedures
1.11
The procedures contained in these Procedures apply to the Framework commonly known or
referred to as the direct entry system, whereby payment instructions are exchanged electronically
in bulk. If any other bulk electronic clearing systems or Frameworks evolve over time which are
subject to the Regulations and for which the Management Committee becomes responsible,
additional separate procedures will be required for those systems.
The next page is 2.1
PART 2
Effect
EFFECT
These Procedures have the effect set out in Part 2 of the Regulations.
PART 3
Conduct of Clearings
3.1
Pursuant to Regulation 11.1 and in addition to and subject to the Regulations, the conduct of
clearings effected between Framework Participants and the settlement of balances arising as a
result of the exchange of Items must be undertaken in accordance with the practices, procedures,
standards and specifications specified in these Procedures.
Amendment
3.2
3.3
Each:
(a) Framework Participant must notify the Company of any changes to its contact points as
specified in Appendix B in accordance with clause 4.1; and
Last amended
effective 11/6/08
(b) Tier 1 Framework Participant must notify the Company of any changes to its Primary
Exchange Arrangements as specified in Appendix K or its Contingency Exchange
Arrangements in Appendix L in accordance with clause 10.2.
Last amended
effective 11/6/08
The Chief Executive Officer may vary Appendix B, Appendix K and Appendix L in accordance
with any such notification without the need to obtain the approval of the Management
Committee or any other person, provided that a variation to Appendix K or Appendix L may
only be made if both of the relevant Tier 1 Framework Participants have notified the Company
of the change.
Last amended
effective 11/6/08
The Chief Executive Officer may vary Appendix F, Appendix G1 and Appendix G2 as may be
required to ensure that they are accurate and up to date without the need to obtain the approval
of the Management Committee or any other person.
Last amended
effective 11/6/08
A variation made by the Chief Executive Officer pursuant to this clause 3.3 will, upon
publication by the Company, be binding on Framework Participants.
Last amended
effective 11/6/08
PART 4
Each Framework Participant must nominate, in writing to the Company, contact points for the
handling of various operational issues or processes, including settlement of payment obligations
via the RITS Low Value Settlement Service, as specified in these Procedures. Details for these
contact points are published in Appendix B Centralized Contact Points.
Last amended
effective 21/05/12
Framework Participants must advise the Company, in writing, of changes to these contact details,
not less than 5 business days prior to such changes taking effect, clearly identifying the effective
date in their advice.
Last amended
effective 1/01/12
BSB Number
4.1A
To facilitate participation in BECS each Framework Participant and each other financial institution
which participates in BECS must have a BSB Number.
Last amended
effective 11/6/08
If a Framework Participant or other financial institution has not already been allocated a BSB
Number by virtue of its participation in another Framework managed by the Company (which
BSB Number is also valid for BECS), a prospective Framework Participant must request
allocation of a BSB Number from the Company when applying to join BECS. Any other financial
institution must have or receive a BSB Number from the Company before it takes any action in
connection with BECS.
Times of Exchange
4.2
Official Exchange Times for Files other than Government Files are 10.00am, 1.00pm, 4.00pm,
6.30pm, 8.45pm and 10.30pm Sydney time each Monday to Friday, excluding National Public
Holidays. Official Exchange Times for Government Files are 7.00am, 6.15pm and 9.00pm
Sydney time each Monday to Friday excluding National Public Holidays on the business day prior
to PD Day. Exchanges of Files with a same day PD Day (on any day on which they are permitted)
must be completed by 10.00pm. Each Tier 1 Framework Participant may only commence
transmitting Files (including Files containing Record Type 1 Items issued by any User, any Return
Files, any Refusal Files):
Last amended
effective 25/11/13
(a)
with respect to Files other than Government Files, at any Official Exchange Time;
Last amended
effective 1/04/02
(b)
with respect to Government Files, at any Official Government File Exchange Time; or
Last amended
effective 1/04/02
(c)
Inserted effective
18/01/02
Each Tier 1 Framework Participant must be ready and able to receive transmissions of Files
commenced at any Official Exchange Time or Official Government File Exchange Time.
Last amended
effective 3/10/06
Each Tier 1 Framework Participant is encouraged to transmit Files other than Government Files at
each of the Official Exchange Times each Monday to Friday excluding National Public Holidays.
Last amended
effective 25/11/13
Each Tier 1 Framework Participant should ensure that each File transmitted by the Tier 1
Framework Participant contains all Items available for exchange at that time.
Last amended
effective 3/10/06
For the avoidance of doubt and notwithstanding any other provision in these Procedures, if a File
is exchanged at the 10.30pm Official Exchange Time then:
Last amended
effective 14/9/09
(a)
the PD Day for that File is the business day after it is exchanged; and
(b)
settlement for that File is to be effected, in accordance with Part 9, on the PD Day.
Last amended
effective 25/11/13
Tier 1 Framework Participants may agree bilaterally to exchange Files at other times, provided the
Tier 1 Framework Participants observe all other provisions of the Regulations and these
Procedures.
Last amended
effective 3/10/06
4.2A
At, or around, the time of transmission of each File or Government File, the transmitting Tier 1
Framework Participant must submit a File Settlement Instruction to the RITS Low Value
Settlement Service, specifying the amount owed to, or by, its Counterparty, calculated by reference
to the net value of Credit Items and Debit Items contained in the File or Government File
transmitted to the Counterparty at that exchange time.
Inserted
effective 21/05/12
4.3
Settlement of obligations arising from exchange of Files, other than Government Files, will be
effected in terms of Part 9 of these Procedures regardless whether exchanges are conducted at
Official Exchange Times or by bilateral agreement. Settlement of obligations arising from
exchange of Government Files will be effected in terms of clause 9.1A of these Procedures,
regardless of whether exchanges are conducted at Official Government File Exchange Times or by
bilateral agreement.
Last amended
effective 1/04/02
Exchange of Items (other than by bilateral agreement) will not take place on National Public
Holidays. On any day other than a National Public Holiday, Tier 1 Framework Participants in
those States/Territories which are closed (for example, because of State/Territory public holidays)
must be available to receive transmissions from all other Tier 1 Framework Participants.
Where normal operations have been adversely affected by extraordinary circumstances, the Chief
Executive Officer may vary the Official Exchange Times, Official Government File Exchange
Times and/or the time by which exchanges must be completed. The Chief Executive Officer will
notify all Framework Participants in writing of any variations under this clause which apply
overnight or longer.
Last amended
effective 1/04/02
4.4
DE File Specifications
4.5
All Items (including Record Type 1 Items issued by any User, Returned Items, Refused Items, and
Reversing Items) and Files (including Files containing Record Type 1 Items issued by any User,
Return Files, Refusal Files and Reversal Files) exchanged between Framework Participants must
conform with requirements set out in Part 12 and the applicable DE File Specifications in
Appendices C1, C2, C3 and C5.
Last amended
effective 4/8/2000
Transaction Codes
4.6
The following transaction codes form part of the DE File User Item Specifications and apply to
Record Type 1 Items issued by Users and exchanged in BECS. All Framework Participants must
ensure that these transaction codes are used where applicable:
Inserted
effective 28/10/96
13
50
51
52
53
54
55
56
57
Reversing FI ID Number
4.17
To facilitate Reversals, each Framework Participant must have a special identification number in
the form 997XXX (where XXX is the relevant BSB Number). That number is referred to in
these Procedures as the Reversing FI ID Number. The Company assigns the Reversing FI ID
Numbers to Framework Participants (see Appendix G1).
Inserted
effective 4/8/2000
Last amended
effective 3/05/04
4.18
Ledger FIs are entitled to rely solely on Account Number Details in all circumstances when
processing Items received by them, regardless of whether any account name details are transmitted
with the Account Number Details or are otherwise known to the Ledger FI. Ledger FIs are not
obliged (including under any duty to the Lodgement FI which may but for this clause 4.18 arise at
law or in equity) to check whether the Account Number Details are correct.
Last amended
effective 3/05/04
(a)
Last amended
effective 3/05/04
4.19
Subject to clause 4.19(b), if an amount has been credited or debited by the Ledger FI in
accordance with the Account Number Details provided by the Lodgement FI but the
amount has been credited or debited to the wrong account, then as between the Lodgement
FI and the Ledger FI, the Ledger FI is not liable to compensate the Lodgement FI, any
person on whose behalf the Lodgement FI exchanges an Item, the intended beneficiary of a
Credit Item, a customer whose account has been wrongly debited or any other person for
any loss or damage. In these circumstances, liability, if any, for compensating any person
for any loss or damage which a person may suffer directly or indirectly in connection with
the wrong crediting or debiting is the responsibility of the Lodgement FI. If a Ledger FI
suffers loss or damage, or receives any claim for loss or damage arising because the
Ledger FI has relied solely on Account Number Details provided by the Lodgement FI
when processing an Item, the Lodgement FI must fully indemnify the Ledger FI in relation
to such loss, damage or claim.
(b)
If an amount has been credited or debited by the Ledger FI in accordance with the Account
Number Details provided by the Lodgement FI but the amount has been credited or debited
to the wrong account due to an account number being reissued or duplicated by the Ledger
FI, then as between the Lodgement FI and the Ledger FI, the Lodgement FI is not liable to
compensate the Ledger FI, any person on whose behalf the Lodgement FI exchanges an
Item, the intended beneficiary of a Credit Item, a customer whose account has been
wrongly debited or any other person for any loss or damage. In these circumstances,
liability, if any, for compensating any person for any loss or damage which a person may
suffer directly or indirectly in connection with the wrong crediting or debiting is the
responsibility of the Ledger FI. If a Lodgement FI suffers loss or damage, or receives any
claim for loss or damage arising because the Ledger FI has relied solely on Account
Number Details provided by the Lodgement FI when processing an Item, but the loss,
damage or claim arises because the relevant account number had been reissued or
duplicated by the Ledger FI, the Ledger FI must fully indemnify the Lodgement FI in
relation to such loss, damage or claim.
(Note: 1.
For the purposes of clauses 4.18 and 4.19, Account Number Details means the BSB
number and the account number or, in the case of a Ledger FI which has a unique
account numbers system, the account number only.
2.
A Summary File must accompany each File and Government File. A Summary File must conform
with requirements set out in Part 14 and the Summary File Specification in Appendix C6.
Inserted
effective 28/10/05
Inserted
effective 23/12/2009
Inserted
effective 16/04/07
Inserted
effective 28/10/05
Inserted
effective 3/05/04
Each Tier 1 Framework Participant must ensure that all of its Direct Connections to Tier 1
Framework Participants are encrypted using triple DES or its equivalent.
(Note: It is recommended that Direct Connections between each Representative and Appointor
should be encrypted using triple DES or its equivalent.)
The next page is 5.1
Inserted
effective 23/12/2009
PART 5
A User FI must ensure that a prospective User is approved in accordance with these Procedures
before the processing of any Items belonging to that User takes place. See clause 5.2 below.
If the User FI gives written notice of termination of its arrangements with a User to the User
then the arrangements between the User and its User FI will be terminated as to future Items but
without prejudice to any right or liability arising under the terms of any proprietary
arrangements with regard to Debit Items between them or under any Credit User Application in
force in accordance with these Procedures.
Last amended
effective 31/3/00
A User FI must notify the details of any of its new Users, any changes to any existing User and
termination of any arrangements with its Users to the Chief Executive Officer in accordance
with clause 5.3.
A Lodgement FI must give at least 30 days prior written notice to all Tier 1 Framework
Participants before it exchanges any Government Files for the first time in BECS. The notice
must specify the date on which the Lodgement FI will commence exchanging Government Files
in BECS (which must not be sooner than 30 days after the expected date of receipt of the notice
by all Tier 1 Framework Participants).
Inserted
effective 22/04/02
Compliance by Users
5.2
issue Credit Items (including by using a Bureau), comply with the requirements specified
in Part 6; and
(b)
In the case of a Credit User, the User FI, and in the case of a Debit User, the Sponsor, must
notify the details of any new User, any changes to any existing User and any termination of
arrangements with a User to the Chief Executive Officer. Notification must be given using an
electronic version of Appendix A17 and/or Appendix A18 using the secure file transfer facility
available on the APCA Extranet.
Last amended
effective 24/01/12
Upon receipt of any notifications referred to above, the BECS UserID Database System will
automatically generate, for the purpose of notifying all Framework Participants, a Daily
Summary Report, which will issue no later than the following business day after such receipt.
A User FI must ensure that a Credit User does not, and a Sponsor must ensure that a Debit User
does not, commence lodging Items or Items reflecting changed details until 3 business days
(inclusive of State/Territory public holidays where these fall on a business day) after the issue of
the relevant Daily Summary Report.
Last amended
effective 26.07.10
5.4
That period is to be inclusive of State/Territory public holidays where these fall on a business
day.
Last amended
effective 04/03/08
[Deleted]
Deleted
effective 14/12/95
5.5
[Deleted]
Deleted
effective 14/12/95
5.6
[Deleted]
Deleted
effective 14/12/95
Last amended
effective 23/12/09
5.7
If a Credit User changes its User FI, the new User FI must ensure that the Credit User executes
fresh Credit User documentation as required by these Procedures. The new User FI must notify
the Company of the change using Appendix A17 (a Debit User/Credit User Change of Name
or Other Details Advice) via the secure file transfer facility available on the Companys extranet.
If a Debit User changes its Sponsor, the new Sponsor must promptly notify the Company using
Appendix A17 (a Debit User/Credit User - Change of Name or Other Details Advice) via the
secure file transfer facility available on the Companys extranet.
Last amended
effective 24/01/12
The outgoing Sponsor (for Debit Users only) must notify the Company in writing of it ceasing
to be a Sponsor in addition to notifying details of termination of arrangements with a User in
accordance with clause 5.3. Notification must be made using Appendix A17 (a Debit
User/Credit User Change of Name or Other Details Advice) via the secure file transfer facility
available on the Companys extranet.
The outgoing User FI (for Credit Users only) is not required to notify the Company of it ceasing
to be the User FI.
Last amended
effective 24/01/12
Inserted
effective 23/12/09
Any person making a claim under a Credit User Application must make a claim under the most
recently executed Credit User Application existing as at the date of the occurrence of the event
or circumstance in respect of which the claim is being made.
Last amended
effective 31/3/00
When a User changes to a new User FI (irrespective of whether that User FI is also the relevant
Sponsor), some operational aspects which should be considered by the new User FI include:
Last amended
effective 1/4/96
(a)
establishing a new TNA in accordance with clause 6.9 for those Users lodging Credit
Items through a Bureau or Lodgement FI;
(b)
changing the name of the User FI on the descriptive record of the User's File; and
(c)
changing the BSB Number and account number in the Trace Record on the User's File.
Cancellation of the existing TNA is the responsibility of the outgoing User FI.
Liquidation or Insolvency of User
5.8
In the event of the liquidation or insolvency of a User, the User may continue to have access to
BECS if:
Last amended
effective 31/3/00
(a) the User FI and, in the case of the Debit User, the Sponsor is prepared to continue its
arrangements with the User. If a Sponsor is prepared to continue to permit a Debit User
access to BECS it does so at its own risk under these Procedures, in particular, clauses 7.5
and 7.6 of these Procedures; and
(b)
the liquidator, trustee in bankruptcy or other person responsible for the administration
("Administrator") of that User confirms that the User, under the administration of the
Administrator, wishes to continue using BECS and, in the case of a Credit User,
confirms the terms of the Credit User Application.
Last amended
effective 31/3/00
If the relevant Sponsor is prepared to continue its arrangements with the Debit User, it must
notify the Chief Executive Officer as soon as practicable, using a Debit User/Credit User Change of Name or Other Details Advice.
Amended
effective 24/01/12
The following provisions apply whenever there is a change of a User's name or where business
of a User, being business which involves direct debit or credit arrangements under BECS, is
transferred to another User (for example as a result of a takeover or merger of the User by or
with another User or a sale of the business or part of the business of the User to another User)
(in this clause 5.9 a transfer of business of the kind referred to above is called a "transfer of
business" and the User to which business is transferred is called the "transferee User"):
(a)
Last amended
effective 31/3/00
if the User which changes its name or transfers business is a Credit User:
(i)
the User FI must ensure that the User or the transferee User, as the case may be,
executes and delivers to the User FI a Credit User Application; and
(ii)
(b)
if the User which changes its name or transfers its business is a Debit User, the
arrangements between the Sponsor and the User, or the transferee User (as applicable)
will be proprietary (including without limitation indemnity arrangements between the
transferee User and the Sponsor in respect of claims arising in connection with Direct
Debit Requests originally given to the User). The Sponsor should advise the User or the
transferee User (as applicable) to notify all of its clients of the circumstances of the
change as soon as practicable and in any case within a period specified by the Sponsor.
The relevant Sponsor must also assess, and is solely accountable for determining, the
transferee Users suitability for continued access to BECS as Debit User;
Last amended
effective 31/3/00
(c)
the relevant User FI or Sponsor (as the case may be) must notify appropriate details of the
change in name or transfer of business (using, in the case of a Debit User, a Debit
User/Credit User - Change of Name or Other Details Advice or a Debit User - Transfer of
Business Advice, as applicable) to the Chief Executive Officer who will then notify all
Framework Participants in accordance with clause 5.3; and
Last amended
effective 24/01/12
(d)
the relevant user FI or Sponsor (as the case may be) in respect of Credit Users and Debit
Users is to instruct:
(i)
(ii)
to change the details on the User's, or transferee User's, File (for example, the User Identification
Number, name of remitter, User preferred name and Trace Record).
Each of the things required to be done under paragraphs (a), (b), (c) and (d) of this clause 5.9
should ideally be done within a reasonable time prior to lodgement of the first File under the
User's new name (in the case of a name change only) or the transferee User's name (in the case
of a transfer of business).
5.10
Deleted
effective 31/3/00
[Deleted]
Trace Record
5.11
Each User FI must ensure that each User which it represents in BECS includes in each of that
Users Files in character positions 81 - 96 of Record Type 1 a correct Trace Record to which an
Item must be returned electronically if it cannot be applied. A Trace Record is usually the same
for each Item on any one File but may be different for some Items or for groups of Items if
required by the User. A financial institution which is not the User FI may be specified in the
Trace Record, but only if it has given its prior written consent to the User FI.
Last amended
effective 27/07/07
(Note: In many cases the Trace Record is also used to satisfy the requirements of the AntiMoney Laundering and Counter-Terrorism Financing Act 2006 (Cth) concerning the inclusion
of Tracing Information in electronic funds transfer instructions. Please refer to Part 5 of the Act
for details.)
User Identification Numbers
5.12
Each User must have a unique User Identification Number issued to it.
A Framework Participant may from time to time contact the Chief Executive Officer and request
a block allocation of User Identification Numbers. The Chief Executive Officer will, upon such
request, make a block allocation available if satisfied that the Framework Participant's annual
usage justifies it. Where a block allocation is made available, the Framework Participant will
issue User Identification Numbers from the block allocation to its new Users. Alternatively, a
request must be made to the Chief Executive Officer for the issue of a User Identification
Number to each individual User and such request must include the full User name and other
relevant details.
In all cases, advices of newly approved Users and their User Identification Numbers must be
notified to the Chief Executive Officer in accordance with clause 5.3. Details of Users and their
User Identification Numbers will be recorded by the Company on its database system.
Framework Participants which issue User Identification Numbers from a block allocation must:
5.13
(a)
establish an appropriate central point or points within their institutions for assignment of
User Identification Numbers. Where more than one point issues User Identification
Numbers, schedules must be separated;
(b)
(c)
before issuing a User Identification Number, ensure that the User is not already recorded
on the Company's database system as a User. If it is, consider treatment as an extension
of usage of the system under the previously issued User Identification Number; and
(d)
in the case of a proposed User which does not proceed to use BECS and whose details
have not been notified to the Company, rule through the name of the User in the schedule
and reissue the User Identification Number to another User.
The Chief Executive Officer will arrange for periodic provision of updated diskettes containing
User data from the Company's database, to any Framework Participant which has formally
requested it.
Clauses 5.14 to 5.22 inclusive are Confidential
PART 6
User FI Approval
6.2
A User FI must ensure that a prospective Credit User makes application to the User FI by
lodging Credit User documentation in accordance with these Procedures and such other
documentation as the User FI requires. Upon receipt of such documentation and if the User FI
approves of the application, the User FI must obtain for, or issue to, the prospective Credit User
a User Identification Number in accordance with clause 5.12 and notify the details of the
prospective Credit User (including the name of any Bureau) to the Chief Executive Officer in
accordance with clause 5.3. The User FI is not obliged to approve any application by a
prospective Credit User.
6.3
A User FI may approve a Credit User without reference to any Framework Participants but
before that approval it must:
6.4
(a)
subject to clause 6.4, ensure the proper completion, execution, stamping (where relevant)
and maintenance of legally binding Credit User documentation (including a Credit User
Application) prior to the prospective Credit User being permitted to lodge Credit Items in
BECS. Credit User documentation must be made available by the User FI (by way of
certified copy) to the Company and any Framework Participant upon request; and
(b)
if the User FI is not also the Lodgement FI, ensure the completion of a TNA prior to the
prospective Credit User being permitted to lodge Credit Items in BECS.
Last amended
effective 14/12/95
The requirement set out in clause 6.3(a) may be waived or varied with the prior written consent
of the Management Committee. The Management Committee will provide its consent where the
User FI undertakes to the satisfaction of the Management Committee to fulfil the obligations of
both a Credit User and a User FI whether or not a Credit User Application is or has been
obtained from the Credit User. In these circumstances, the documentation which exists between
the User FI and the Credit User is proprietary.
User FI Responsibilities
6.5
Last amended
effective 1/11/08
Amended effective
01/07/12
(iii) promptly notify the Customer upon completion of processing a Notice of Variation
of Account Details.
Inserted effective
01/07/12
(b)
maintain control over the Credit User's lodgement of Credit Items and be solely
accountable for terminating the Credit User's right to lodge Credit Items as it sees fit;
Inserted
effective 28/10/96
ensure that:
(i) the Credit User has a correct Trace Record for each transaction on its File; and
(ii) if the Trace Record Institution specified or to be specified in respect of the Credit
Users Credit Items is not the User FI, that Trace Record Institution has consented
in writing to be specified as the Trace Record Institution for that Users Credit
Items.
6.6
(c)
If the User FI conducts the account nominated in the Trace Record, the User FI must
accept every Returned Item which is sent to it electronically by the Ledger FI as a Record
Type 2 in accordance with the Regulations and these Procedures (see in particular clauses
5.16A(f), 5.17, 5.18 and 8.1);
Last amended
effective 11/6/08
(d)
except in relation to Government Payments, not exchange Credit Users Credit Items with
a "Date to be Processed" in Record Type "0" other than on the date which is the date
specified in that field (although future dated Credit Items may be exchanged with other
financial institutions in accordance with bilateral arrangements);
Last amended
effective 1/04/02
(e)
accept Returned Items on behalf of the Credit User where such Items were incorrectly
applied to a Ledger FI account by virtue of incorrect details being supplied by the Credit
User;
(f)
notify the Company within the appropriate time frame prior to change of Credit User
name, mergers and the like taking effect in accordance with clause 5.3;
Last amended
effective 1/11/08
(g)
keep copies of all Credit User documentation while the Credit User remains a Credit User
and for a period of seven years from the date that Credit User ceases to be a Credit User;
Last amended
effective 1/11/08
(h)
promptly forward to the Credit User any Notice of Redirection of a Direct Entry Item
received (addressed to the Credit User) from a Ledger FI (as referred to in clause 5.21);
and
(i)
forward a Notice of Variation of Account Details (addressed to the Credit User) to the
Credit User within 3 business days of receipt.
Amended effective
01/07/12
Each User FI agrees that upon exchange of Credit Items, each such Credit Item represents
cleared funds and that Recalls and Returns of the Credit Items cannot be made without consent
of the Ledger FI or its Representative. See clauses 5.14, 5.16 and 5.17. Each User FI also
agrees that Reversals may only be made in accordance with the procedures set out in clause
5.16A.
Last amended
effective 18/01/02
Ledger FI Responsibilities
6.7
A Ledger FI must:
Last amended
effective 28/10/96
(a)
6.7A
(i)
receive each Credit Users Credit Items sent by the Sending Member, apply
funds to the relevant Customers' accounts as at a date no later than the PD Day
(or the next business day after the PD Day if the PD Day is a public holiday in
the relevant State/Territory) and effect settlement in accordance with the
Regulations and these Procedures;
Last amended
effective 5/12/07
(ii)
unless otherwise agreed bilaterally between the User FI and the Ledger FI,
Credit Items received by the Ledger FI must be posted to the Ledger FI's
accounts dated as at PD Day (or the next business day after PD Day if the PD
Day is a public holiday in the relevant State/Territory);
Last amended
effective 5/12/07
(iii)
subject to clause 6.7A, make Credit Items which have been posted to the Ledger
FIs accounts pursuant to clause 6.7(a)(ii), other than Government Payments,
available to the Customer in the normal course of operations by 9.00 am local
time on the next business day after PD Day (or the second business day after PD
Day if the PD Day is a public holiday in the relevant State/Territory); and
Last amended
effective 5/12/07
(iv)
Last amended
effective 5/12/07
(Note: The Anti-Money Laundering and Counter-Terrorism Financing Act 2006 (Cth) imposes
pre-conditions which must be satisfied before financial institutions may initiate, pass on or take
any other action to carry out electronic funds transfer instructions. Please refer to Part 5 of the
Act for details.)
Inserted
effective 16/04/07
(b)
return any Credit Users Credit Items electronically which cannot or will not be applied,
no later than the close of business on the next business day after the PD Day (or the
second business day after PD Day if the PD Day is a public holiday in the relevant
State/Territory);
Last amended
effective 5/12/07
(c)
assist its Customers with enquiries on Credit Items made to the Customers' accounts;
(d)
ensure that the name of remitter and, where present, the lodgement reference details from
the Detail Record are printed on all Customer statements;
(e)
if it receives any Refused Item (Record Type 3) which it cannot accept, ascertain from the
Detail Record for that Refused Item the identity of the relevant User FI and arrange onforwarding of the Refused Item in accordance with that User FIs directions; and
Last amended
effective 1/11/08
(f)
Last amended
effective 1/11/08
A Ledger FI is only obliged to make Credit Items available to the Customer for which it has
received value settlement in accordance with Part 9 of these Procedures.
Inserted effective
01/07/12
Inserted effective
08/01/07
Inserted effective
01/07/12
6.7B
request, via the APCA Mailbox, and obtain, a Regular Payments List on behalf of the
Switching Customer from the Outgoing FI; and
(b)
upon receipt of the Regular Payments List (whether from the Switching Customer or
from the Outgoing FI via the APCA Mailbox) assist the Switching Customer to notify
Credit Users of a change in the account to be credited by:
(i)
assisting the Switching Customer to identify the Credit Users on the Regular
Payments List that need to receive a Notice of Variation of Account Details;
(ii)
(iii)
Inserted effective
01/07/12
(Note: under clause 6.7G the Outgoing FI is obliged to provide the Customer with a Regular
Payments List upon request.)
Inserted effective
01/07/12
Inserted effective
01/07/12
(Note: The Outgoing FI should make such inquiries as is necessary, having regard to the type of
account to which the request relates, to satisfy itself that a request received from an Incoming FI
is a Valid Request as defined. This may include comparison of the customers signature (as
provided on the request) with any specimen signature for that customer held by the Outgoing FI,
checking account name(s) and account authority/ies. Under no circumstances will the Outgoing
FI be obliged to contact its customer to validate the request.)
Inserted effective
01/07/12
6.7D
If an Outgoing FI determines that a request is not a Valid Request, it must immediately notify
the Incoming FI and provide reasons for its determination.
Inserted effective
01/07/12
6.7E
An Outgoing FI is deemed to have received a request under clause 6.7C if the request is sent by
the Incoming FI to the Outgoing FI via the APCA Mailbox.
Inserted effective
01/07/12
6.7F
An Incoming FI which obtains a Regular Payments List on behalf of a Switching Customer from
an Outgoing FI under clause 6.7B, indemnifies the Outgoing FI in respect of all claims,
liabilities, expenses and losses suffered or incurred by the Outgoing FI arising from the
Outgoing FIs disclosure of the Regular Payments List.
Inserted effective
01/07/12
6.7C
Inserted effective
01/07/12
6.7G
Inserted effective
01/07/12
provide the Customer with a Regular Payments List as soon as practicable and in any
event within 5 business days of receiving the request; and
(b)
assist the Customer to notify Credit Users of a change in the account to be credited by:
(i)
assisting the Customer to identify the Credit Users on the Regular Payments List
that need to receive a Notice of Variation of Account Details;
(ii)
(iii)
Inserted effective
01/07/12
(Note: The Notice of Variation of Account Details is used whenever a Credit User is to be
notified via the User FI of a change in its customers account to be credited.)
Inserted effective
01/07/12
Lodgement FI Responsibilities
6.8
Last amended
effective 18/01/02
(a)
each Credit Users Files and Items which are exchanged conform with the DE File User
Item Specifications (see Appendix C1) prior to them being exchanged;
Last amended
effective 27/07/07
(b)
the Credit User has a correct Trace Record for each transaction on the Credit Files lodged
by the Lodgement FI; and
Last amended
effective 27/07/07
(c)
when Government Files are exchanged, they are not transmitted with other Files except
pursuant to a bilateral agreement (see clause 4.2 for exchange times).
Last amended
effective 27/07/07
(Note: The Anti-Money Laundering and Counter-Terrorism Financing Act 2006 (Cth) requires
that certain information must be included in electronic funds transfer instructions and that
certain information must be obtained in respect of those instructions before financial institutions
may initiate, pass on or take any other action to carry out the electronic funds transfer
instructions. Please refer to Part 5 of the Act for details.)
Inserted
effective 16/04/07
Lodgement FIs processing and receiving transactions for a third party should agree with that
third party as to who is to check Files received for correctness and who will create any necessary
Return Files, Refusal Files and Reversal Files.
Last amended
effective 4/8/2000
The Lodgement FI must check that, if a TNA is required in accordance with clause 6.9, a TNA is
held for the relevant Credit User's File and that the total value of such File is within the amount
authorised by the TNA.
Last amended
effective 27/07/07
Where the Lodgement FI is not the User FI and the Lodgement FI processes a File for a User
where the total value of the File exceeds the amount authorised by the current TNA for that
User, the File is processed at the risk of the Lodgement FI unless the excess is first approved by
the User FI. The Lodgement FI should seek the User FI's approval in writing or by some other
mutually agreed method through the TNA Excesses Contact Point of the User FI specified in
Appendix B4.
Last amended
effective 25/6/07
It is the Lodgement FI's responsibility to satisfy itself that any File received from a Bureau or
User for processing under TNA drawings is genuine (ie that it has in fact been provided by the
Bureau or User).
Establishment of a TNA by the User FI is mandatory whenever a Credit User's File (prepared
either by the Credit User or a Bureau) is to be processed by a Lodgement FI which is other than
the User FI. Each relevant TNA Issuer is to supply the necessary TNA (see Appendix A8) to the
Lodgement FIs TNA Contact Point specified in Appendix B10.
Last amended
effective 25/6/07
For the avoidance of doubt, nothing in these Procedures requires a TNA to be obtained where
the Lodgement FI is also the User FI but the funding account is held with another financial
institution.
The TNA, which is to be prepared in accordance with the relevant TNA Issuer's internal
requirements, authorises processing of a File up to the value of a specified processing limit, limit
frequency and period and guarantees payment of the drawing for the total value of such File plus
any charges levied by the Lodgement FI, as applicable.
Last amended
effective 14/12/95
A TNA Issuer may temporarily increase the authorised amount of a TNA, in order to
accommodate certain extraordinary payments (eg Christmas payroll), by issuing formal advices
in writing to the Lodgement FI's TNA Contact Point.
Last amended
Effective 25/6/07
Last amended
effective 25/6/07
For the purposes of confirming TNAs, each User FI's TNA Contact Point will, as appropriate
from time to time, supply to each other User FI's TNA Contact Point, a list of authorised
signatories using the Authorised TNA Signatories form set out in Appendix A23.
Last amended
effective 25/6/07
Subject to clause 6.10, where there is any change to the instructions contained in the original
TNA, a replacement TNA must be prepared, authorised and forwarded to the Lodgement FIs
TNA Contact Point.
Last amended
effective 25/6/07
A TNA may only be terminated by the Lodgement FI or the relevant TNA Issuer. Advice of
termination must be in writing to the other party's TNA Contact Point. Termination is effective
upon receipt by the other party of the written termination advice, provided that a Lodgement FI
may be unable to immediately act on advice of termination of a TNA which is received after
commencement of processing of the User's File to which the TNA relates.
Last amended
effective 29/6/05
(Note: A TNA Issuer should be aware of its obligations with respect to blocked accounts
pursuant to Part III of the Financial Transactions Reports Act (the FTRA). In particular
when an account is blocked TNA Issuers should consider whether it is necessary to terminate the
TNAs in respect of the blocked account to ensure compliance with the FTRA.)
Inserted
effective 11/10/06
If a User or Bureau wishes to change its Lodgement FI, the relevant TNAs must be transferred
or replaced at the relevant TNA Issuer's option prior to any Files being processed by the new
Lodgement FI. If transfer is the preferred method the following procedures must be followed
and a suitable start date arranged that allows for at least four weeks for the transfer process to be
completed:
Last amended
effective 14/12/95
(a)
the proposed Lodgement FI must ensure that the User or Bureau provides it with a letter
requesting it to take over the existing Lodgement FI's processing role together with a list
of the existing TNAs held by the Bureau specifying:
(b)
a separate listing in BSB Number order is to be provided for each TNA Issuer;
(c)
the proposed Lodgement FI must write to the existing Lodgement FI and request transfer
of business and assignment of the benefit of the existing TNAs. A copy of the
User/Bureau's request (referred to in paragraph (a) above) must be enclosed;
(d)
the existing Lodgement FI must reply by forwarding a letter to the proposed Lodgement
FI, enclosing the originals of all existing TNAs. The existing Lodgement FI must retain a
copy of the existing TNAs sent to the proposed Lodgement FI;
(e)
on receipt, the proposed Lodgement FI must check the TNAs received against the list
provided by the User or Bureau, confirm any discrepancies and forward a letter to each
TNA Issuer together with a schedule of TNAs showing details outlined above. A copy of
the existing Lodgement FI's reply should be forwarded to each TNA Issuer;
Last amended
effective 14/12/95
(f)
the TNA Issuer must confirm each TNA to the proposed Lodgement FI;
Last amended
effective 14/12/95
(g)
the TNA Issuer must ensure that the Credit User is aware of the change if the change is
initiated by the Bureau;
Last amended
effective 14/12/95
(h)
the proposed Lodgement FI must ensure that the Record Type 1 (Detail Record) field is
amended as necessary; and
Last amended
effective 28/10/96
(i)
the TNA Issuer must notify the Chief Executive Officer of individual changes in
accordance with clause 5.3.
Last amended
effective 14/12/95
Credit Users who are Responsible Entities/Trustees/Managers of Trusts, Superannuation Funds etc.
Last amended
effective 15/10/99
6.11
Last amended
effective 15/10/99
Where the responsible entity/trustee/manager has the power to give but has insufficient assets of
its own to support such an indemnity, or otherwise refuses personal liability under such an
indemnity, the User FI must ascertain whether the responsible entity/trustee/manager is entitled
under the trust deed/constitution (as appropriate) to recover from the assets of the managed
investment scheme, trust, superannuation fund or other fund any amount which it may become
liable to pay under the indemnity given under a Credit User Application.
Last amended
effective 15/10/99
If the responsible entity/trustee/manager has recourse to the assets of the managed investment
scheme, trust, superannuation fund or other fund, the application may be supported by the
balance sheet of the managed investment scheme, trust, superannuation fund or other fund and
the following clause may be added to the Credit User application (without the need to obtain the
consent of the Management Committee):
Last amended
effective 15/10/99
"8.
The indemnity contained in Clause 3 of this Credit User Application is given by the
Credit User as responsible entity/trustee/manager of the ...... (Managed
Investment Scheme/Trust/Fund) and, except in the case of fraud, negligence, breach of
trust or breach of duty by the Credit User, liability under that Clause 3 is limited to the
value of the assets of the said . (Managed Investment Scheme/Trust/Fund)
under its administration from time to time."
Last amended
effective 15/10/99
If the responsible entity/trustee/manager has no recourse to the assets of the managed investment
scheme, trust, superannuation fund or other fund under the trust deed/constitution (as
appropriate), this clause must not be included, the responsible entity/trustee/manager will be
liable in its own right, and any Credit User Application must be supported by the responsible
entity/trustee/manager's own balance sheet.
Last amended
effective 15/10/99
It is the responsibility of the User FI to appropriately stamp the Credit User Application in the
relevant stamp duty jurisdiction. (In this regard note that at the date these Procedures come into
effect all State and Territories of Australia apply their respective stamp duty laws to instruments
signed in those States or Territories, and there are additional nexus provisions (which vary from
State to State and Territory to Territory) which may apply if a Credit User Application signed in
one State or Territory is physically held in another State or Territory or relates to a matter to be
done in another State or Territory)."
Notification of an Unapplied Credit Item and Request for Information (Superannuation Entities)
6.13
Inserted
effective 21/3/95
(b)
then the Ledger FI may seek further particulars of the Credit Item from the Credit User by
sending a Notice of Unapplied Credit Item (Superannuation) form set out in Appendix A26 to the
Lodgement FIs Notice of Unapplied Credit Item (Superannuation) Contact Point specified in
Appendix B13 by facsimile or email (as a rich text format attached).
On receipt of a Notice of Unapplied Credit Item (Superannuation) a Lodgement FI must:
(a)
(b)
within 20 business days from the date of receipt of the Notice of Unapplied Credit Item
(Superannuation), send a written response to the Ledger FI (to the fax number or email
address specified in the Notice of Unapplied Credit Item (Superannuation)).
If on receipt of any further particulars supplied by the Credit User the funds still cannot be
applied or if no response to the Notice of Unapplied Credit Item (Superannuation) is received
within 20 business days from the date of sending the Notice of Unapplied Credit Item
(Superannuation) to the Lodgement FI, then the unapplied Credit Item may be returned by the
Superannuation Entity to the Trace Record account as a new Record Type 1 using transaction
code 50 and quoting the:
(a)
reference details from Notice of Unapplied Credit Item (Superannuation) in the lodgement
reference field; and
(b)
title of account from the original Credit Item in the name of remitter field.
Any return of an unapplied Credit Item by a Superannuation Entity pursuant to this clause 6.13
must be sent to the Trace Record account within 90 business days of receipt of the Credit Item.
If the unapplied Credit Item is returned by the Superannuation Entity to the Trace Record account
and the account has been closed then the Credit Item must be returned with the answer Account
Closed. The Superannuation Entity should then treat the funds as Unclaimed Moneys.
Changes to contact details in Appendix B13 must be promptly notified to the Company in
accordance with clause 4.1
(Note: Clause 6.13 is only to be used as a last resort. Superannuation Entities should have
appropriate reconciliation systems in place, so that a Notice of Unapplied Credit Item
(Superannuation) is only issued when absolutely necessary (for example due to a Credit User
(Employer) error.)
PART 7
Any Framework Participant may sponsor a person as a Debit User. A Tier 2 Framework
Participant must, however, have the agreement of its Representative to sponsor a person as a
Debit User. Where a Tier 2 Framework Participant has the agreement of its Representative to
sponsor a person as a Debit User, the Representative will be deemed to have given the
indemnification set out in clause 7.7. The arrangements under which a Tier 2 Framework
Participant's Representative agrees to the Tier 2 Framework Participant sponsoring a person as a
Debit User are proprietary.
(Note: a Framework Participant may be a Debit User. In such a case, the Framework
Participant is responsible for complying with the provisions of this Part 7 as a Sponsor and as a
DE User.)
Inserted
effective 20/03/13
Sponsor Approval
7.2
A Sponsor may approve a person as a Debit User without reference to any other Framework
Participants, but before that approval it must carry out a credit risk assessment of the prospective
Debit User and satisfy itself that the financial strength, integrity and reliability of the prospective
Debit User qualify it as a suitable Debit User in BECS. A Sponsor is not obliged to approve any
prospective Debit User.
Last amended
effective 31/3/00
Documentation brought into effect between the Sponsor and a Debit User in connection with the
Debit User's participation in BECS in that capacity and the Sponsor's obligation, as Sponsor, to
ensure the Debit User meets certain obligations and responsibilities required of it under this Part
7 (see, for example, clauses 7.5, 7.10 and 7.11) is proprietary.
Inserted
effective 31/3/00
(Note: Ledger FIs have recourse against a Sponsor for claims arising pursuant to the Debit
User's participation in BECS: see clauses 7.5(b) and 7.6.)
7.3
Each Framework Participant may use a logo approved by the Company in connection with direct
debits in BECS on any of that Framework Participants proprietary documentation published in
accordance with these Procedures and relating to the provision by it of direct debit services
through BECS. Each Framework Participant acknowledges and agrees for the benefit of the
Company that its entitlement to use any such logo ceases immediately upon its ceasing to act in
the capacity of a Framework Participant in BECS, and that subsequent use of the logo by it will
be taken to be an infringement of the Companys rights in that mark.
Inserted
effective 31/3/00
If a Sponsor approves a person as a Debit User, the Sponsor must obtain for, or assign to, the
prospective Debit User a User Identification Number in accordance with clause 5.12. The
Sponsor must notify the details of the prospective Debit User and, in the case of a Sponsor
which is a Tier 2 Framework Participant, its Representative's agreement to the Tier 2 Framework
Participant sponsoring the prospective Debit User, to the Chief Executive Officer in accordance
with clause 5.3.
Last amended
effective 31/3/00
Inserted
effective 31/3/00
7.3A
Subject to clause 7.4A, a Direct Debit Request may only be given in writing or by telephone by
the relevant Customer to and in favour of a Debit User (or to a third party in its capacity as agent
for that named Debit User).
7.4
(Note: A DDR may be given in writing by electronic communication see clauses 1.2 (e) and (f)
and 7.10 (a).)
(a)
Last amended
effective 31/03/04
(b)
authorise and request a Debit User to debit a Customer's account through BECS;
(c)
identify (by name and BSB Number) the Ledger FI to which the relevant debit payment
instructions are to be given. Provision of domicile (ie. physical address) is optional;
(d)
identify (by name and account number) the Customer's account to be debited;
(e)
identify (by name and User Identification Number) the Debit User in favour of which the
Customer's authority is given; and
(f)
if given:
(i)
(ii)
Last amended
effective 30/6/03
(A)
(B)
provide the Customer with written confirmation of the Direct Debit Request
(which must include the information described in 7.4(c), (d) and (e) above)
and the terms and conditions of the applicable DDR Service Agreement
within 7 days.
(Note: 1.
Clause 7.14 sets out further requirements in relation to the printing/ publication of
written Direct Debit Requests and use of the Company logo.
2.
A Debit User must obtain written authorisation from its Sponsor BEFORE it may
obtain DDRs in writing by electronic communication or by telephone see clause
7.10(b).
3.
Appendix A27 is provided to assist Sponsors with preparation of their DDRs insofar
as it suggests a form of DDR incorporating all required content. Notwithstanding
any implied or express statement to the contrary in these Procedures, provided
DDRs comply with substantive content provisions of these Procedures, a Sponsor
may determine the form of DDR it uses in its absolute discretion.)
Inserted
Effective 17/01/11
Transitional
Inserted
effective 31/3/00
7.4A
Inserted
effective 31/3/00
A Sponsor may approve a Debit User's use, in the DDR Transitional Period, of Forms PD-C in a
format previously approved by the Sponsor under these Procedures, in lieu of Direct Debit
Requests in the form required by clause 7.4.
Any Form PD-C so approved for use in the DDR Transitional Period will be treated in all
respects for the purposes of these Procedures as if it were a Direct Debit Request EXCEPT
THAT the Sponsor must require the Debit User to deliver each such Form PD-C to the Ledger
FI to which it is addressed, and retain a copy for the Debit Users records.
Inserted
effective 31/3/00
Each Ledger FI which receives a Form PD-C completed by a Customer during the DDR
Transitional Period must retain it for a period of not less than 7 years from the date of the last
debit effected under it.
Inserted
effective 31/3/00
On and from the DDR Compliance Date, each Sponsor must ensure that its Debit Users do not
permit Customers to enter into direct debit arrangements in BECS using Forms PD-C.
Inserted
effective 31/3/00
Sponsor Responsibilities
7.5
ensure that the Debit User complies with its responsibilities as set out in these
Procedures;
(b)
indemnify each Ledger FI against claims arising from the Debit User issuing Debit Items
through BECS, in the terms set out in clause 7.6;
Last amended
effective 31/3/00
(c)
ensure that:
Inserted
effective 28/10/96
(d)
(i)
the Debit User has a correct Trace Record for each transaction on its File; and
(ii)
If the Sponsor conducts the account nominated in the Trace Record, the Sponsor must
accept every Returned Item which is sent to it electronically as a Record Type 2 in
accordance with the Regulations and these Procedures (see in particular clauses 5.16A(f),
5.17, 5.18 and 8.1). The Sponsor must inform the Debit User promptly of each such
Returned Item referable to that Debit User;
Last amended
effective 11/6/08
manage the on-going conduct of the Debit User by ensuring that the Debit Users
lodgements are consistent with the Debit User's normal business practice or needs and
install a "User Profile" to monitor File lodgements and manage unusual variations to
lodgement patterns on an on-going basis. In monitoring File lodgements by its Debit
Users, a Sponsor must have regard to:
Last amended
effective 28/10/96
(i)
the total value of Debit Items contained in any one File being in excess of the
agreed figure or in excess of the normal pattern;
(ii)
(iii)
(e)
be satisfied as to the Debit Users continued financial stability and continued suitability
for access to BECS and, where required, undertake reviews to the extent necessary;
Last amended
effective 31/3/00
(f)
be solely accountable for terminating the Debit User's right to lodge Debit Items as it sees
fit;
Last amended
effective 28/10/96
(g)
immediately review a Debit User's suitability if the Sponsor becomes aware of any
material change in the Debit User's circumstances. If, as a result of the review, the
Sponsor cancels the Debit Users access to BECS as a Debit User, the Sponsor must
notify the Company and the Debit User immediately of such cancellation (and the Debit
User should also be notified of the withdrawal of its entitlement and access to any logo of
the Company relating to direct debits). The Company will then issue a cancellation
advice to the Framework Participants according to the urgency of the request. A change
to a Debit User's circumstances may include, without limitation, reduced financial
standing, integrity or reliability;
Last amended
effective 2/04/04
(h)
notify the Company within the appropriate time-frame prior to change of Debit User
name, mergers, and the like taking effect in accordance with clause 5.3;
Last amended
effective 20/7/2001
(i)
notify the Company not less than 5 business days before making any change to its DDR
Claims Contact or Claims Account details as published in Appendix B7, nominating an
effective date for the change, to enable the Company to publish any amended details to
Framework Participants before they take effect;
Last amended
effective 24/01/12
(j)
promptly forward to the Debit User a Direct Debit Cancellation Request received from a
Ledger FI (as referred to in clause 7.12(h));
Last amended
effective 01/07/12
(k)
promptly forward to the Debit User any Notice of Redirection of a Direct Entry Item
received (addressed to the Debit User) from a Ledger FI (as referred to in clause 5.21);
(l)
forward a Notice of Variation of Account Details (addressed to the Debit User) to the
Debit User within 3 business days of receipt; and
Amended effective
01/07/12
(m)
notify the Debit User that before obtaining Direct Debit Requests in writing by electronic
communication or by telephone the Sponsor must review and approve the format,
content, medium and procedures proposed for obtaining Direct Debit Requests in writing
by electronic communication or by telephone.
Last amended
effective 1/11/08
Sponsor Indemnification
7.6
A Sponsor which approves a Debit User indemnifies all Framework Participants on behalf of
themselves and on behalf of each Non-member Appointor for which that Framework Participant
is a Representative in respect of all claims, liabilities, expenses and losses suffered or incurred
by the Framework Participant and each Non-member Appointor in respect of all Valid Claims in
accordance with this clause.
In this clause, a "Valid Claim" is a claim, supported by full particulars, made in writing by a
Framework Participant, addressed to the Sponsor in relation to the Framework Participant's
Customer or its Non-member Appointor's Customer to whose account a Debit Item is debited,
that:
Last amended
effective 31/3/00
(a)
the account of any such Customer has been debited with, and payment made to the Debit
User of, amounts not at the time authorised by a Direct Debit Request from that
Customer, or to which the Debit User was not at the time legally entitled;
Last amended
effective 31/3/00
(b)
the account of any such Customer has been debited with, and payment made otherwise
than in accordance with a Direct Debit Request in force at that time from that Customer;
or
Inserted
effective 31/3/00
(c)
payment has failed to be made in accordance with a Direct Debit Request in force at that
time from that Customer,
Inserted
effective 31/3/00
that the Sponsor has accepted as meeting all conditions under this clause; or
Last amended
effective 31/3/00
(e)
that the Sponsor has accepted liability for irrespective of the circumstances; or
Last amended
effective 31/3/00
(f)
where any relevant industry ombudsman or a court makes a decision or an order that the
Sponsor make a payment in respect of the claim.
Last amended
effective 31/3/00
The indemnification contained in this clause 7.6 shall apply to each Debit User which has or
should have been advised to be a Debit User by the Sponsor to the Company in accordance with
these Procedures whether such advice was given on or before the commencement of BECS. In
the case of a Debit User which was not using the direct entry system operating immediately prior
to the commencement of BECS this indemnification commences to apply to that Debit User
upon the Debit User lodging Files in accordance with these Procedures.
Representative Indemnification
7.7
A Representative which has agreed to allow a Tier 2 Framework Participant to sponsor a person
as a Debit User indemnifies all Framework Participants (other than the Tier 2 Framework
Participant), on behalf of themselves and on behalf of each Non-member Appointor for which
that Framework Participant is a Representative, in respect of any loss caused by or arising from
the Tier 2 Framework Participant's failure to comply with the indemnity which it has given
under clause 7.6 as a Sponsor and its failure to comply with any other aspect of Sponsor
obligations in clause 7.
The procedures for Ledger FIs to claim under the Sponsor's indemnification as set out in clause
7.6 and the Representative's indemnification as set out in clause 7.7 are as follows:
Last amended
effective 1/3/2002
Deleted effective
1/3/2002
(a)
(ii)
(Note: as far as practicable, Ledger FIs are encouraged to include a check of their own
PD-C files (ie. pre-DDR Compliance Date) as part of this determination.)
Inserted
effective 31/3/00
(iii)
if it determines that the claim appears to be a Valid Claim, obtain from the
Customer a completed Customer Claim which must:
Last amended
effective 31/3/00
(A)
Inserted
effective 31/3/00
(B)
Inserted
effective 31/3/00
(iv)
(b)
(c)
(C)
identify the Debit User or, if different, remitter named on the Customers
account statement;
Inserted
effective 31/3/00
(D)
identify (by date, amount, BSB Number and account number) the
disputed debit transaction and include the lodgement reference details
printed on the Customer's account statement;
Inserted
effective 31/3/00
(E)
set out the basis on which the Customer disputes the Debit User's
authority to debit; and
Inserted
effective 31/3/00
(F)
Amended
effective 24/01/12
after receiving a completed Customer Claim, if the Ledger FI decides to make a claim
under clause 7.6 and/or clause 7.7, the Ledger FI's DDR Claims Contact specified in
Appendix B7 must, before close of business on the business day (in the State/Territory
where that DDR Claims Contact is located) which next follows the date of the Customer
Claim:
Last amended
effective 11/6/08
(i)
provide full particulars of the claim, including the date of the claim and the
information referred to in clause 7.8(a)(iii)(B)-(E) inclusive, by facsimile or by email to the Sponsor's DDR Claims Contact specified in Appendix B7, together
with a completed Claim Request, demanding payment by the Sponsor, under the
indemnity given by the Sponsor pursuant to clause 7.6, of the amount of the claim;
and at the same time,
Last amended
effective 24/01/12
(ii)
Last amended
effective 31/3/00
Last amended
effective 11/6/08
(i)
forward the claim to the Debit User as soon as practicable and require it to
produce evidence of its authority to effect the disputed debit transaction; and
Inserted
effective 31/3/00
(ii)
respond in writing to the Ledger FI's DDR Claims Contact (with a copy to the
Sponsor's Representative, if any) as to whether the claim is accepted or refused
(and if it is refused, written reasons for that, together with evidence of the Debit
User's authority to effect the disputed debit):
Last amended
effective 11/6/08
(A)
in the case of disputed debits made no earlier than 12 months before the
date of the Customer Claim (apart from disputed debits involving a Debit
User that is under the administration of an Administrator (as defined in
clause 5.8)), by no later than close of business on the fifth business day
(in the State/Territory where the Sponsor's DDR Claims Contact is
located) after its receipt of the claim; and
Last amended
effective 1/11/08
(B)
in the case of all other disputed debits, within one month of its receipt of
the claim;
Inserted
effective 31/3/00
(Note: the intention is to allow the Sponsor's DDR Claims Contact 5 clear business days to
process a claim under (A) above. Ledger FIs must ensure, in calculating the date by which a
response is required from the Sponsor, that they exclude public holidays in the State/Territory
where the Sponsor's DDR Claims Contact is located.)
Last amended
effective 11/6/08
(d)
the Ledger FI must inform the Customer of the Sponsor's response no later than the
morning of the next business day (being a business day in each of the States/Territories
(if different) where the Ledger FI and the Ledger FI's DDR Claims Contact are located)
following the expiry of the period allowed for the Sponsor's response under clause
7.8(c)(ii)(A) or (B);
Last amended
effective 11/6/08
(e)
if the Sponsor accepts any claim or if it fails to respond to the Ledger FI's DDR Claims
Contact within the specified period under clause 7.8(c)(ii)(A) or (B), the Ledger FI may:
Last amended
effective 11/6/08
(i)
Inserted
effective 31/3/00
(ii)
Last amended
effective 04/03/08
(f)
at the time it notifies the Customer under clause 7.8(d). The Ledger FI must confirm its
drawing by facsimile to the Sponsors DDR Claims Contact on the same business day
that it effects the drawing, providing in that facsimile adequate information to enable the
Sponsor to identify the claim which is the basis of that drawing. On and from the DDR
Compliance Date all drawings pursuant to clause 7.8(e)(ii) must be made electronically in
accordance with the specifications set out in Appendix C4;
Last amended
effective 11/6/08
if in relation to any claim, the Sponsor's DDR Claims Contact notifies the Ledger FI's
DDR Claims Contact in writing within the required period pursuant to clause 7.8(c)(ii)
that the claim is refused, it must at that time produce to the Ledger FI's DDR Claims
Contact evidence of the authority of the Debit User to have made the disputed debit
(DDR Claims Evidence), and:
Last amended
effective 11/6/08
(i)
(ii)
the Ledger FI determines, in its reasonable opinion, that the claim is still
appropriate, then
the Ledger FI must give written notice that rejection of the claim is disputed to the
Sponsor, and if the Sponsor is a Tier 2 Framework Participant, copied to the Sponsor's
Representative;
Last amended
effective 31/3/00
(g)
upon receipt by the Sponsor and, if applicable, its Representative of notice under clause
7.8(f), the Sponsor and the Ledger FI and, if applicable, the Representative must use
reasonable endeavours to resolve the dispute;
(h)
if a disputed claim is not resolved under clause 7.8(g) within 30 days from the date on
which the Sponsor (or if applicable, the later of the respective dates on which the Sponsor
and its Representative) received notice of the dispute under clause 7.8(f), the disputed
claim may be referred to the Management Committee, pursuant to Regulation 13, by the
Ledger FI or the Sponsor or, if applicable, the Sponsor's Representative;
(i)
any claim in respect of which the DDR Claims Evidence does not include a copy of a
valid and binding written Direct Debit Request with a signature that has been handwritten
by the Customer shall be determined in favour of the Ledger FI unless the Sponsor can
establish conclusively that the Debit User has obtained a valid and binding Direct Debit
Request from the Customer in writing by electronic communication or by telephone.
For the avoidance of doubt, nothing in the preceding provisions of this clause 7.8 will be taken
to prevent a Ledger FI, having determined that in its opinion a claim is a Valid Claim, from
refunding, from its own funds, to the Customer the amount of the disputed Debit Item before
making its claim on the Sponsor in accordance with clause 7.8(b). In that case, once the Ledger
FI makes a claim on the Sponsor under clause 7.8(b), clauses 7.8(c)-(i) inclusive will then apply
in accordance with their terms EXCEPT THAT risk as to whether the claim will be accepted by
the Sponsor (or, if disputed, as to whether it will ultimately be determined to be a Valid Claim)
rests solely with the Ledger FI and any funds subsequently refunded to the Ledger FI pursuant to
this clause 7.8 will be taken to be received or drawn by it for its own benefit.
If the Customer commences legal action against the Ledger FI, the Ledger FI must keep the
Sponsor and, if applicable, the Sponsor Representative reasonably informed about that legal
action. Each Sponsor consents to being joined as a party to any such action if the Ledger FI so
requires, with each party to be responsible in the first instance for its own costs. It may also be
that the Sponsor and/or the Sponsor's Representative will wish to become involved in the legal
action to defend its involvement in processing the transaction.
Last amended
effective 31/3/00
Last amended
effective 31/3/00
7.9
Last amended
effective 31/3/00
Upon notification to the Company of the cancellation of a Debit User's right of access to BECS
as a Debit User, the Sponsor indemnification given under clause 7.6 and, if applicable, the
Representative indemnification under clause 7.7 shall cease to apply in respect of that Debit
User in relation to Items of that Debit User exchanged by it after that notification, but without
prejudice to any right or liability arising under the Sponsor indemnification given under clause
7.6 in relation to that Debit User prior to such cancellation or in relation to any other Debit Users
lodging for whom that Sponsor is responsible and, if applicable, the Representative
indemnification given under clause 7.7.
A Sponsor must not approve a prospective Debit User unless the Debit User agrees to comply
with all the conditions, accountabilities and responsibilities required of a Debit User in these
Procedures. Therefore, a Sponsor must ensure that its Debit Users:
(a)
Last amended
effective 31/3/00
(i)
obtain a valid and binding Direct Debit Request that meets the requirements
specified in clause 7.4;
(ii)
enter into a DDR Service Agreement that meets the requirements specified in
clause 7.11 either in writing or by telephone and if the DDR Service Agreement is
entered into:
(A)
(B)
(2)
provide the Customer with the terms and conditions of the DDR Service
Agreement in writing. If the terms and conditions of DDR Service Agreement are
provided to the Customer in writing by electronic communication then the
requirements specified in clause 1.2(e) must be satisfied; and
(iv)
(Note: If a DDR is obtained by telephone then written confirmation of the DDR and the
terms and conditions of the applicable DDR Service Agreement must be provided
to the Customer within 7 days see clause 7.4(f)(ii)(B).)
(b)
(c)
in respect of each existing Customer as at the DDR Implementation Date who has not
received a DDR Service Agreement:
(i)
agree to apply, for the benefit of those Customers, the procedures and policies set
out in the Debit User's standard DDR Service Agreement applicable at the relevant
time; and
Inserted
effective 31/3/00
(ii)
Inserted
effective 31/3/00
(d)
issue Debit Items strictly in accordance with the Direct Debit Request provided by the
Customer to the Debit User, honour the spirit of the commitment made to the Customer
under the Debit User's applicable DDR Service Agreement and do not exceed the
conditions (if any) specified in the Direct Debit Request provided by the Customer;
(e)
inform Customers of any change in the terms of the debit arrangements agreed between
them (in the case of new Customers on and from the DDR Implementation Date, as set
out in the Debit User's DDR Service Agreement and Direct Debit Request and includes,
without limitation, any change to the Debit User's details as set out in the Direct Debit
Request), at least 14 days before the change is implemented;
(f)
inform the Sponsor (within any notification period specified by the Sponsor) of any
significant changes in arrangements made in relation to the issue of Debit Items including
changes to File values and/or frequency;
(g)
(h)
(i)
(j)
(k)
inform the Sponsor of any proposed change to Debit User name, mergers, and the like in
accordance with any notification period specified by the Sponsor;
(Note: such a notification period may be necessary to enable the Sponsor to evaluate
the nature of the proposed change and to determine whether or not to agree to it
and, in the event that it agrees, to act in accordance with clauses 5.3 and 5.9.)
Inserted
effective 31/3/00
Inserted effective
01/07/12
(i)
Amended effective
01/07/12
(ii)
Last amended
effective 01/07/12
(i)
Last amended
effective 1/11/08
(ii)
Last amended
effective 1/11/08
(iii)
Amended effective
01/07/12
(iv)
Inserted effective
1/11/08
(Note: In relation to any Returned Item referable to a Debit User, the Debit User must
act promptly to take such action as may be necessary, which may include
referring to the Customer, to ensure the continuing accuracy of each Direct
Debit Request.)
Inserted effective
26.07.10
investigate and deal promptly and in good faith with any query, claim or complaint
relating to alleged incorrect or wrongful debits that is received from a Sponsor, assist the
Sponsor to deal with all such queries, claims or complaints and respond to the Sponsor
within any period specified by the Sponsor, by either
Last amended
effective 1/11/08
(i)
accepting the claim and paying the disputed amount to the Sponsor in any manner
agreed between them; or
(ii)
disputing the claim and providing the Sponsor with full particulars of reasons for
disputing the claim, which must include evidence of its authority to debit;
Last amended
effective 1/11/08
the Debit Users responsibility to ensure that correct account information appears
on any Direct Debit Request given to it; and
(ii)
the Sponsors potential liability under its indemnity in clause 7.6 (and the
implications in terms of any liability of the Debit User to that Sponsor under their
proprietary documentation) in circumstances where the Debit User has initiated
debits in reliance on incorrect account information provided by a Customer in a
Direct Debit Request;
(l)
ensure the correct User Identification Number for the Debit User appears on each Direct
Debit Request, and all correspondence to the Customer which the Debit User initiates;
Last amended
effective 1/11/08
(m)
retain all Direct Debit Requests, Notice of Variation of Account Details, Notices of
Redirection of a Direct Entry Item and instructions from Customers (whether received
directly from a Customer or via a Ledger FI (or Incoming FI) and Sponsor) to cancel or
suspend a Direct Debit Request given to the Debit User in writing (other than by
electronic communication or by telephone) and reliable records of all such requests,
forms or instructions given to the Debit User in writing by electronic communication or
by telephone on or after the DDR Implementation Date (including copies of all Forms
PD-C which are required to be delivered to the Ledger FI (see clause 7.4A)) for a period
of not less than 7 years from the date of the last debit made under the relevant Direct
Debit Request, and produce these on request by the Sponsor or the Ledger FI for
verification of the Debit User's authority to debit;
Last amended
effective 01/07/12
(n)
acknowledge and agree, for the benefit of the Company, that the Debit Users entitlement
to use a logo approved by the Company on its form of Direct Debit Request and related
material (in each case as approved by the Sponsor), is contingent on the Debit Users
continuing to act in the capacity of a Debit User in BECS and to comply fully with its
obligations in that capacity, such that if:
Last amended
effective 1/11/08
(o)
(i)
(ii)
the Debit Users entitlement to use that logo will cease immediately and any further use
of the logo by the Debit User will be taken to be an infringement of the Companys rights
in that mark; and
Last amended
effective 20/7/2001
acknowledge and agree that Customers are entitled to cancel or suspend Direct Debit
Requests addressed by those Customers to those Debit Users by notice to the Ledger FIs
in accordance with sub-paragraph 7.12(h).
Last amended
effective 1/11/08
Inserted
effective 31/3/00
7.11
Inserted
effective 31/3/00
(a)
Last amended
effective 17/01/11
(b)
set out reasonable details (or, if such details are contained in the DDR, refer the Customer
to it) of the terms of the debit arrangements to apply between the Debit User and the
Customer including, if applicable, the basis on which the Debit User will issue billing
advices to the Customer;
Inserted
effective 31/3/00
(c)
provide for not less than 14 days' notice to the Customer if the Debit User proposes to
vary any of the terms of those debit arrangements;
Inserted
effective 31/3/00
(d)
set out in reasonable detail the procedure available to the Customer to request deferment
of, or alteration to, any of those arrangements;
Inserted
effective 31/3/00
(e)
set out in reasonable detail the procedure available to the Customer to stop any Debit
Item or cancel a Direct Debit Request with the Debit User, and advise the Customer that
all requests for such stops or cancellations may be directed to the Debit User or the
Ledger FI;
Last amended
effective 19/2/04
(f)
set out in reasonable detail the procedure available to the Customer to dispute any Debit
Item with the Debit User and the dispute resolution process to apply between them, and
advise the Customer that claims may also be directed to the Ledger FI;
Last amended
effective 19/2/04
(g)
indicate:
Inserted
effective 31/3/00
(i)
that direct debiting through BECS may not be available on all accounts; and
(ii)
that the Customer is advised to check account details against a recent statement
from the Ledger FI,
and direct the Customer, if uncertain, to check with the Ledger FI before completing the
DDR;
Inserted
effective 31/3/00
(h)
state that it is the responsibility of the Customer to have sufficient clear funds available in
the relevant account by the due date to permit the payment of Debit Items initiated in
accordance with the relevant Direct Debit Request;
Inserted
effective 31/3/00
(i)
state its policy when the due date for payment falls on a day which is not a Business Day
in the place of lodgement, and indicate that if the Customer is uncertain as to when the
debit will be processed to the Customer's account, he or she should enquire direct of the
Ledger FI;
Inserted
effective 31/3/00
(j)
state its policy when Debit Items are returned unpaid by the Ledger FI, including the
application by the Debit User of any related fees; and
Inserted
effective 31/3/00
(k)
state its policy on the privacy to be accorded to the Customer's records and account
details, while noting that the Sponsor may require such information to be provided in
connection with a claim made on it relating to an alleged incorrect or wrongful debit.
Inserted
effective 31/3/00
(Note: 1.
2.
Appendix A28 is provided to assist Sponsors with preparation of their DDR Service
Agreements, insofar as it suggests a form of DDR Service Agreement incorporating
all required content. Notwithstanding any implied or express statement to the
contrary in these Procedures, provided DDR Service Agreements comply with
substantive content provisions of these Procedures, a Sponsor may determine the
form of DDR Service Agreement it uses in its absolute discretion.)
Inserted
Effective date 17/01/11
A Ledger FI must:
(a)
receive Debit Users Debit Items from a Sending Member, draw funds from the relevant
Customers' accounts as at a date no later than PD Day (or the next business day after PD
Day if the PD Day is a public holiday in the relevant State/Territory) and effect
settlement in accordance with the Regulations and these Procedures. Unless otherwise
agreed bilaterally between the User FI and Ledger FI, Debit Items received by the Ledger
FI must be posted to the Customers account as at PD Day (or the next business day after
PD Day if the PD Day is a public holiday in the relevant State/Territory).
Last amended
effective 5/12/07
(Note: The Anti-Money Laundering and Counter-Terrorism Financing Act 2006 (Cth) requires
that certain information must be included in electronic funds transfer instructions and imposes
pre-conditions which must be satisfied before financial institutions may initiate, pass on or take
any other action to carry out the electronic funds transfer instructions. Please refer to Part 5 of
the Act for details.)
Inserted
effective 16/04/07
(b)
return any Debit Items which cannot or will not be paid, no later than the close of
business on the next business day after the PD Day (or the second business day after PD
Day if the PD Day is a public holiday in the relevant State/Territory) in accordance with
clause 7.15;
Last amended
Effective 5/12/07
(c)
assist its Customers with enquiries on Debit Items made to the Customers' accounts;
Last amended
effective 31/3/00
(d)
Last amended
effective 04/03/08
(e)
ensure that the name of remitter and, where present, the lodgement reference details from
the Detail Record are printed on all Customer statements;
Last amended
effective 31/3/00
(f)
if it receives any Refused Item (Record Type 3) which it cannot accept, ascertain from the
Detail Record for that Refused Item the identity of the relevant Sponsor and arrange onforwarding of that Refused Item in accordance with that Sponsors directions;
Last amended
effective 31/3/00
(g)
notify the Company not less than 5 business days before making any change to its DDR
Claims Contact or Claims Account details as published in Appendix B7, nominating an
effective date for the change, to enable the Company to publish any amended details to
Framework Participants before they take effect;
Last amended
effective 24/01/12
(h)
Last amended
effective 01/07/12
But nothing in this Part 7 is to be taken to require a Ledger FI to accept and post Debit Items to a
Customer's account when:
(i)
(ii)
the Debit Item will be returned in accordance with clause 7.15(b) because it will not be
paid.
A Ledger FI that does not post a Debit Item to a Customers account because of the
circumstances described in (i) or (ii) above is not relieved of the obligation to effect settlement
for that Debit Item in accordance with the Regulations and these Procedures.
Last amended
effective 1/11/08
Last amended
effective 1/11/08
Inserted effective
1/11/08
Inserted effective
1/11/08
Deleted
effective 20/7/2001
Deleted
effective 31/3/00
Inserted effective
01/07/12
Inserted effective
01/07/12
The Incoming FI will also assist the customer to cancel any Direct Debit Requests the customer
wishes to discontinue.
7.12A
request, via the APCA Mailbox, and obtain a Regular Payments List, on behalf of the
Switching Customer, from the Outgoing FI;
(b)
assist the Switching Customer to notify Debit Users of a change in the account to be
debited by:
(i)
assisting the Switching Customer to identify the Debit Users on the Regular
Payments List that need to receive a Notice of Variation of Account Details;
(ii)
(iii)
Inserted effective
01/07/12
(c)
assist a Switching Customer to notify a Debit User of its wish to cancel a Direct Debit
Request by:
(i)
assisting the Switching Customer to identify, on the Regular Payments List, any
Direct Debit Request that it wishes to cancel;
(ii)
(iii)
forwarding the signed Direct Debit Cancellation Request to the Outgoing FI and
each applicable Sponsor via the APCA Mailbox or to each applicable Sponsors
Account Switching Contact Point (specified in Appendix B12) within 2 business
days of the Switching Customer signing it,
Note: In accordance with clause 7.5, a Sponsor is obliged to promptly forward a copy of a
Direct Debit Cancellation Request to the Debit User, and under clause 7.10, to ensure each
Debit User acts promptly in relation to any instruction given by or on behalf of a customer to
cancel a Direct Debit Request.
7.12B
Subject to clause 7.12C, an Outgoing FI which receives a request from an Incoming FI, which it
determines to be a Valid Request must provide the Incoming FI with a Regular Payments List
via the APCA Mailbox as soon as practicable and in any event within 5 business days of
receiving the Valid Request.
Inserted effective
01/07/12
Note: The Outgoing FI should make such as enquiries as is necessary, having regard to the type
of account to which the request relates, to satisfy itself that a request received from an Incoming
FI is a Valid Request as defined. This may include comparison of the customers signature (as
provided on the request) with any specimen signature for that customer held by the Outgoing FI,
checking account name(s) and account authority/ies. Under no circumstances will the Outgoing
FI be obliged to contact its customer to validate the request.
7.12C
If an Outgoing FI determines that a request is not a Valid Request, it must notify the Incoming
FI and provide reasons for its determination.
Inserted effective
01/07/12
7.12D
An Incoming FI which requests and obtains a Regular Payments List on behalf of a Switching
Customer from an Outgoing FI under clause 7.12A, indemnifies the Outgoing FI in respect of all
claims, liabilities, expenses and losses suffered or incurred by the Outgoing FI arising from the
Outgoing FIs disclosure of the Regular Payments List.
Inserted effective
01/07/12
Inserted effective
01/07/12
7.12E
Inserted effective
01/07/12
provide the Customer with a Regular Payments List as soon as practicable and in any
event within 5 business days of receiving the request; and
(b)
assist the Customer to notify Debit Users of a change in the account to be debited by:
(i)
assisting the Customer to identify the Debit Users on the Regular Payments List
that need to receive a Notice of Variation of Account Details;
(ii)
(iii)
Inserted effective
01/07/12
Note: The Notice of Variation of Account Details is used whenever a Debit User is to be notified
(via its Sponsor) of a change in its customers account to be debited.
Inserted effective
01/07/12
Inserted
effective 31/3/00
7.13
Inserted
effective 31/3/00
each Debit Users Files and Items which are exchanged conform with the DE File User
Item Specifications (see Appendix C1) prior to their being exchanged;
(Note: The Anti-Money Laundering and Counter-Terrorism Financing Act 2006 (Cth) requires
that certain information must be included in electronic funds transfer instructions and that
certain information must be obtained in respect of those instructions before financial institutions
may initiate, pass on or take any other action to carry out the electronic funds transfer
instructions. Please refer to Part 5 of the Act for details.)
(b)
if it is not itself the Sponsor, approval in writing has been obtained from the Sponsor
prior to lodging the Debit Files on behalf of the User;
(c)
the Debit User has a correct Trace Record for each transaction on the Debit Files lodged
by the Lodgement FI ;
(d)
if the Trace Record Institution specified or to be specified in respect of the Debit Users
Debit Items is not the Sponsor, that Trace Record Institution has consented in writing to
be specified as the Trace Record Institution for that Debit Users Debit Items; and
(e)
the Debit Users lodgements are consistent with the Debit Users normal business
practice or needs and systems are in place to monitor File lodgements and manage
unusual variations to lodgement patterns on an on-going basis.
If the Lodgement FI is not itself the Sponsor and lodges Debit Files for a User without having
obtained prior approval from the Sponsor of that User for the time being, the Lodgement FI is
held liable in respect of all Debit Items lodged by it, for all purposes under these Procedures as if
it were the Sponsor, that is, for all responsibilities as prescribed in clause 7.5 of the Procedures
(including without limitation the Sponsors indemnity referred to in clause 7.5(b)). For this
purpose, any such Lodgement FI must ensure its DDR Claims Contact and Claims Account
details are published in Appendix B7 and that it notifies the Company not less than 5 business
days before making any change to those details, nominating an effective date for the change, to
enable the Company to publish any amended details to Framework Participants before they take
effect.
Form PD-C
Inserted
effective 16/04/07
Last amended
effective 24/01/12
Deleted
effective 31/3/00
[deleted]
Inserted
effective 31/3/00
7.14
Last amended
effective 31/3/00
A Sponsor must notify a prospective Debit User and, where relevant, an existing Debit User :
(a)
that the Sponsor must check and approve the format, content and medium proposed for a
Direct Debit Request and any information which these Procedures require a Sponsor to
ensure is given to Customers in connection with the Direct Debit Request (including
without limitation the DDR Service Agreement) BEFORE printing or other formal
means of publication to Customers is undertaken by the Debit User;
(b)
that the Debit User may include its logo on the Direct Debit Request or other related
material approved by the Sponsor for the purposes of, and in accordance with, these
Procedures;
that the Debit User may include a logo approved by the Company for use in connection
with the provision of direct debit services in BECS (as notified by the Sponsor) on the
Direct Debit Request and other related material approved by the Sponsor for the purposes
of, and in accordance with, these Procedures BUT ONLY for as long as the Debit User
continues to comply fully with its obligations as a Debit User.
(c)
The Sponsor, on behalf of the Company, must ensure that the Debit User uses any logo of the
Company strictly as required by clause 7.14(c) and ceases to use any such logo immediately
upon its access to BECS as a Debit User being withdrawn by the Sponsor or otherwise ceasing.
Unpaid Direct Debits
7.15
paid; or
(b)
returned electronically to the Trace Record Institution by no later than the close of
business on the next business day after the PD Day (or the second business day after PD
Day if the PD Day is a public holiday in the relevant State/Territory).
For the avoidance of doubt, the electronic return of a Debit Item to the BSB Number and
account number in character positions 81 to 96 inclusive of the Detail Record for that Debit Item
is sufficient for the purposes of clause 7.15(b) above.
Last amended
effective 28/10/96
Last amended
effective 5/12/07
Inserted
effective 27/07/07
File/Item Rejection
Confidential
PART 8
FILE/ITEM REJECTION
(Confidential)
The next page is 9.1
PART 9
Settlement
SETTLEMENT
Date of Settlement
9.1
9.1A
Subject to clause 9.1A, settlement between Tier 1 Framework Participants must be effected;
Last amended
effective 25/11/13
(a)
in the case of Items exchanged at the 10.30pm Official Exchange Time, in the Nine AM
(9am) Settlement on the PD Day; or
inserted
effective 25/11/13
(b) in the case of all other Items, in the next scheduled Multilateral Intraday Settlement on the
PD Day,
inserted
effective 25/11/13
unless the Tier 1 Framework Participants who are parties to the transaction bilaterally agree to
an earlier individual settlement, if permitted by the rules governing RITS.
inserted
effective 25/11/13
If, due to exceptional circumstances, settlement is not effected on the PD Day, it must be
effected by 9.00am Sydney time on the business day after the PD Day, with an interest
adjustment on balances owing being passed between Tier 1 Framework Participants in
accordance with clause 9.2F, or otherwise at such times and in such manner and at such rates
and in respect of such type or types of Items as may be determined from time to time by the
Management Committee.
Last amended
effective 25/11/13
Subject to Regulation 12.6 and the regulations and procedures or manual governing any other
Framework, Tier 1 Framework Participants may submit a File Settlement Instruction for value
settlement amounts which relate to payment instructions which are exchanged between
Framework Participants but which payment instructions are not Items exchanged in BECS.
Amended
effective 21/05/12
If such value settlement amounts for payment instructions which are exchanged between
Framework Participants but which are not Items are incorporated into a File Settlement
Instruction with respect to value settlement for Items exchanged in BECS, then settlement of
such amounts must be performed in accordance with the provisions of the Regulations and these
Procedures (including without limitation any provisions applicable where an FTS Event occurs)
as though those payment instructions are Items exchanged in BECS.
Amended
effective 21/05/12
Last amended
effective 25/11/13
Method of Settlement
9.2
The procedures detailed in this clause 9.2 do not apply to settlements of the type referred to in
clause 9.1A.
Inserted
effective 16/4/99
Subject to clause 9.4, settlement must be effected in Exchange Settlement Funds for the net
amount owing between each Tier 1 Framework Participant and all other Tier 1 Framework
Participants.
Last amended
effective 25/11/13
9.2A
Settlement
Amended
effective 25/11/13
9.2B
When a Tier 1 Framework Participant is manually entering File Settlement Instructions into
RITS due to a specific processing difficulty it is not necessary to manually enter $0 File
Settlement Instructions. However if manual entry is being used as a business-as-usual mode of
operation then entry of $0 File Settlement Instructions is still required.
Inserted
effective 20/03/13
Inserted
effective 21/05/12
In the event that a File Settlement Instruction is rejected by the RITS Low Value Settlement
Service, the Originator must promptly review and rectify all defects in the original File
Settlement Instruction and submit a revised File Settlement Instruction, if required. The
Originator should promptly notify its Counterparty, by its LVSS Contact, of the estimated timing
of submission of a revised File Settlement Instruction.
9.2C
Inserted
effective 21/05/12
9.2D
Inserted
effective 21/05/12
9.2E
Inserted
effective 21/05/12
Disputed Amounts
Subject to the rules governing the RITS Low Value Settlement Service, if at any time prior to
settlement a Counterparty disputes any value or reference to a number of Files within a File
Settlement Instruction submitted by an Originator, it will promptly notify the Originator. The
Originator must review the disputed value or number in the File Settlement Instruction and, if it
identifies any error, promptly:
(a) submit a File Recall Instruction to recall that particular File Settlement Instruction; and
Settlement
Interest Adjustments
Inserted
effective 21/05/12
Where settlement in respect of any exchange of any Item is (for whatever reason) effected on a
day other than the PD Day (in this rule 9.2F, referred to as a Deferred Settlement
Obligation), the creditor and debtor Tier 1 Framework Participants must make an adjustment
of interest between them in respect of that Item calculated at the interest rate (termed the ESR
by the Reserve Bank of Australia) payable by the Reserve Bank of Australia on overnight credit
balances of Exchange Settlement Accounts held with the Reserve Bank of Australia.
Amended
effective 25/11/13
(b)
9.2G
Amended
effective 25/11/13
(i)
calculate the interest on the net position between each Tier 1 Framework
Participant for the number of days elapsed between the PD Day and the day of
settlement using the ESR applicable to each of those days during that period; and
Amended
effective 25/11/13
(ii)
Amended
effective 25/11/13
Amended
effective 25/11/13
Settlement under these Procedures will be effected for the net amount owing between each Tier
1 Framework Participant and all other Tier 1 Framework Participants, being the aggregate
amount of all File Settlement Instructions submitted at an Official Exchange Time or other
bilaterally agreed exchange time.
Amended
effective 25/11/13
9.2H
Settlement
For each Nine AM (9am) Settlement and Multilateral Intraday Settlement, RITS will generate
for each Tier 1 Framework Participant a final settlement figure to be payable to or receivable by
that Tier 1 Framework Participant and after computing and making adjustments for (on a
multilateral net basis) the final net cross Framework settlement figure for that Tier 1 Framework
Participant as a consequence of its participation in the Bulk Electronic Clearing System
Framework (CS2) and any other Framework operating on a multilateral settlement basis
(including but not limited to the High Value Clearing System Framework (CS4) if that system is
settling on a multilateral settlement basis in fall back mode because settlements cannot occur in
real time as a result of some contingency). The generation by RITS will be deemed to notify
that Tier 1 Framework Participant of its final settlement figure and final net cross Framework
settlement figure for that settlement. At the time of deemed notification the Tier 1 Framework
Participant must settle its final net cross Framework settlement figure.
Last amended
effective 25/11/13
The Reserve Bank of Australia will directly apply to the Exchange Settlement Accounts of Tier
1 Framework Participants entries in accordance with the final net cross Framework settlement
figures generated by the RITS Low Value Settlement Service.
Last amended
effective 21/05/12
Inserted
effective 25/11/13
9.2I
(a)
subject to sub-clause 9.2H(b), any File Settlement Instruction which is submitted after
the time of formation of a Multilateral Intraday Settlement group may be settled
individually if the individual settlement method is selected in RITS or will otherwise be
held in RITS for settlement in the next scheduled Multilateral Intraday Settlement; and
(b)
any File Settlement Instruction which is submitted after the time of formation of the
final Multilateral Intraday Settlement group may be settled individually if the individual
settlement method is selected in RITS, or must otherwise be resubmitted for settlement
at in the next scheduled Nine AM (9am) Settlement.
Inserted
effective 25/11/13
if the final scheduled Multilateral Intraday Settlement is not completed (for whatever
reason), any unsettled File Settlement Instruction will be tested for and, where possible,
settled by, individual settlement in RITS; and
(b)
if, at the end of Evening Settlement Session, any such File Settlement Instruction
remains unsettled, it must be resubmitted for settlement in the next Nine AM (9am)
Settlement.
Clause 9.3 is Confidential
On any day which is a holiday in both Sydney and Melbourne, settlement will be deferred to the
next day which is a business day in Sydney or Melbourne or both.
Last amended
effective 21/05/12
Settlement
Inserted
effective 21/05/12
The RITS Low Value Settlement Service facility must be used to submit File Settlement
Instructions, File Recall Instructions, and to receive responses and advices which the Framework
Participant has elected to receive. Tier 1 Framework Participants must establish and maintain
contingency arrangements to ensure that File Settlement Instructions and, if necessary, File
Recall Instructions, can be manually submitted during any type of contingency event.
In the event that member user access to RITS is unavailable such that RITS Low Value
Settlement Service instructions cannot be entered, viewed or managed, then affected Tier 1
Framework Participants must immediately contact the RITS Help Desk by telephone and request
assistance and otherwise comply with the requirements set out in Part 10 of these Procedures and
the requirements of the LVSS BCP Arrangements.
As soon as an applicant is advised by the Secretary that its application for BECS Tier 1
membership has been accepted it must contact the RITS Help Desk to arrange testing and
implementation of its functional connectivity to the RITS Low Value Settlement Service. The
business rules and technical specifications for the RITS Low Value Settlement Service and the
LVSS BCP Arrangements can be accessed via links on the Companys extranet.
PART 10
Contingency Procedures
CONTINGENCY PROCEDURES
Responsibilities
10.1
Framework Participants have a responsibility to each other and to BECS as a whole, to cooperate in resolving any processing difficulties including during Contingencies.
To the extent that such co-operation does not adversely affect its own processing environment, a
Framework Participant receiving a request for assistance may not unreasonably withhold such
assistance.
All Tier 1 Framework Participants must include the use of email as a minimum contingency
exchange arrangement.
Inserted
effective 30/06/03
10.1A
If bilaterally agreed contingency exchange arrangements are invoked as part of the half yearly
testing of such contingency arrangements, the Sending Institution must ensure that files sent are
not duplicated.
Last amended
effective 1/11/08
10.1.B
Inserted
effective 03/04/06
Where processing difficulties occur, depending upon the circumstances, remedial action could
include:
Last amended
effective 30/06/03
(a)
Last amended
effective 30/06/03
(b)
invoking bilaterally agreed arrangements which are in place and recorded in Appendix L;
Last amended
effective 30/06/03
(c)
Last amended
effective 30/06/03
(d)
invoking use of bilaterally agreed physical medium for contingency exchanges where the
use of electronic communications for primary and contingency exchange arrangements
are rendered unusable.
Inserted effective
23/09/02
Options
10.2
If bilaterally agreed contingency exchange arrangements are invoked, the sending or Disabled
Tier 1 Framework Participant must complete and forward a Contingency File Exchange Form
(as set out in Appendix M1) to the receiving Tier 1 Framework Participant.
Inserted
effective 30/06/03
All Tier 1 Framework Participants are required to record all agreed primary exchange
arrangements in the BECS Procedures Appendix K and immediately notify the Company of any
changes to these arrangements.
Last amended
effective 30/06/03
All Tier 1 Framework Participants are required to record all bilaterally agreed contingency
exchange arrangements in the BECS Procedures Appendix L and immediately notify the
Company of any changes to these arrangements.
Last amended
effective 30/06/03
Contingency Procedures
10.2A
In the event of processing difficulty or other contingency event, notwithstanding any other
remedial action which might be taken, the Chief Executive Officer may, if he considers it
appropriate to do so, invoke the Member Incident Plan, which is available on the Companys
Extranet, either by written notice to, or verbally notifying, the Management Committee. The
Member Incident Plan provides a framework for Management Committee communication and
consultation during applicable contingency events. If the Chief Executive Officer invokes the
Member Incident Plan, the Management Committee will comply with its requirements.
Inserted
effective 20/03/13
10.3
Deleted effective
23/09/02
Last amended
effective 23/09/02
10.4
Full identifying information relating to ownership of the physical medium and the details of
contents must be marked on each piece of physical medium exchanged. Such information is to
include the following:
Last amended
effective 23/09/02
Last amended
effective 23/09/02
creation date;
Item number n of Total Items (eg. cartridge 1 of 3);
date to be processed; and
Sending or Disabled Tier 1 Framework Participants full name and return address.
Last amended
effective 30/06/03
Last amended
effective 23/09/02
10.5
Last amended
effective 30/06/03
The industry standard for physical medium is compact disc. The following read/write format
standards apply unless other formatting is bilaterally agreed between exchanging parties:
CD-ROM
Other forms of physical medium used must be bilaterally agreed between exchanging parties.
Structure of File
10.6
Last amended
effective 23/09/02
Contingency Procedures
Multi User
Single User
Descriptive
Detail
File Total
(0)
(1)
(7)
Descriptive
Detail
File Total
(0)
(1)
(7)
Descriptive
Detail
File Total
(0)
(1)
(7)
Return/Refusal Files
10.7
Descriptive
Detail
File Total
(0)
(2)
(7)
Descriptive
Detail
File Total
(0)
(3)
(7)
Descriptive
Detail
Detail
File Total
(0)
(2)
(3)
(7)
Descriptive
Detail
Detail
File Total
(0)
(3)
(2)
(7)
Deleted effective
23/09/02
Contingency Procedures
Inserted effective
23/09/02
10.9
Tier 1 Framework Participants who experience partial or total loss of primary exchange
arrangements, resulting in a Disabling Event (see Appendix I, clause 5.2), may be required to
invoke contingency exchange arrangements with other Tier 1 Framework Participants. The
industry standard for these arrangements is bilaterally agreed alternate electronic
communications.
Last amended
effective 04/03/08
10.9A
Tier 1 Framework Participants must establish, and periodically test, contingency arrangements to
ensure that File Settlement Instructions and, if necessary, File Recall Instructions can be
manually submitted during any loss of connectivity to the RITS Low Value Settlement Service.
The industry standard for testing such contingency arrangements is set out in the LVSS BCP
Arrangements which may be accessed via a link on the Companys extranet.
Inserted
effective 21/05/12
Inserted effective
23/09/02
10.10
A Tier 1 Framework Participant must bilaterally test its contingency exchange arrangements,
which may be alternate electronic communications or a secondary method of contingency
exchange arrangements, with a minimum of one other Tier 1 Framework Participants at least
once each calendar half year and in accordance with the Contingency Exchange Testing
Schedule.
Last amended
effective 11/6/08
The Contingency Exchange Testing Schedule specifies the Tier 1 Framework Participants with
which to conduct testing on a rotating regular basis to ensure that the contingency exchange
arrangements with all Tier 1 Framework Participants are tested over a period of time that is no
more than four calendar years apart. TheContingency Exchange Testing Schedule will be
revised in the event of the admission or resignation of a Tier 1 Framework Participant or a
change in the capacity in which a Tier 1 Framework Participant participates in the Bulk
Electronic Clearing System Framework (CS2).
Last amended
effective 1/11/08
A Tier 1 Framework Participant must send live data (DE transaction data and the associated DE
summary file) using the contingency exchange arrangement and the data received must be used
to process actual live transactions. Transmitting duplicate data during the test using primary
exchange arrangements is not permitted.
Inserted effective
03/04/06
To test members ability to use the RITS facility that provides for the manual entry of File
Settlement Instructions, each Tier 1 Framework Participant must manually input some or all of
the File Settlement Instructions corresponding to the Files exchanged in bilateral testing of
contingency exchange arrangements.
Inserted effective
25/03/14
In addition, Tier 1 Framework Participants using physical medium for contingency exchange
arrangements must complete a successful test of each bilateral arrangement at least once each
calendar half year until replaced with alternate electronic communications.
Last amended
effective 11/6/08
Inserted effective
23/09/02
10.11
All Tier 1 Framework Participants must sign a Contingency Procedures Testing Certificate each
calendar half year to certify that the Tier 1 Framework Participant has successfully tested its
contingency exchange arrangements in accordance with clause 10.10.
Last amended
effective 1/11/08
The Company will issue all Tier 1 Framework Participants with a memorandum and
Contingency Procedures Testing Certificate each calendar half year requesting Tier 1
Framework Participants to finalise all bilateral testing and sign the Certificate. The Certificate
must be returned to the Company in the time frames specified.
Last amended
effective 11/6/08
Contingency Procedures
The Management Committee will be advised of all outcomes including any Tier 1 Framework
Participant who fails to provide a signed Certificate. The Management Committee will
determine the course of action required.
Inserted effective
30/06/03
following minimum
(a)
(b)
the maximum file size which can be attached to the email must not exceed 5 Megabytes
(MB);
(c)
the email security package must, at a minimum, include the following encryption features:
(i)
the ability to prevent viewing of email and its attachments by outside parties other
than the intended recipient;
(ii)
the ability to prevent the email and its attachments being read by unauthorised
persons within your organisation;
(iii)
the ability to prevent viewing of email and its attachments by outside parties other
than the intended recipient;
(iv)
the ability to prevent the email and its attachments being read by unauthorised
persons within your organisation;
(v)
the ability to securely send the email and its attachments locked with a public key;
(vi)
the ability of the recipient to open the email and its attachments by unlocking the
transmission with a securely generated private key;
(vii)
the ability of the sender to digitally sign the email transmission; and
(d) the following naming conventions for the email are recommended, however members may
bilaterally agree to variations:
(i)
Amended effective
19/07/11
(ii)
xx = file number 01-99. For each Disabling Event the file number commences at
01 and increases by 1 for each file (irrespective of file type), until processing
returns to normal, even if the Disabling Event spans several days. This ensures that
each file has a unique file number.
Contingency Procedures
(iv)
(v)
(vi)
(vii)
(viii) Each email must contain one file only. Members can agree to include more than
one File by bilateral agreement and in this case the File names in the subject line
must be separated by a slash (/).
(ix)
The Sending Member must send the email to the nominated email address provided
by the Receiving Member on the email file exchange contacts database managed by
the Company. The email address should preferably be a generic address (eg.
operations@FI.com.au) rather than an individuals address (eg. Mike@FI.com.au).
(x)
Members can agree to exchange zipped files by bilateral agreement. The file name
will have an extension of .zip.
Inserted effective
30/06/03
Where a Tier 1 Framework Participant uses an email security package which requires the
exchange of public keys to securely send and read emails, the Tier 1 Framework Participant
must have lodged any of its public keys in the email file exchange contacts database maintained
by the Company.
The email file exchange contacts database is managed by the Company and Tier 1 Framework
Participants are required to nominate an authorised contact to access the database for lodgement
and downloading of public keys and provide the following details:
Framework;
full name;
ACN/ARBN/ABN;
mnemonic;
public key;
All Tier 1 Framework Participants must complete and lodge an online Email File Exchange
Contacts Lodgement Form (as set out in Appendix M2) including attachment of the public keys
for use by other Tier 1 Framework Participants. The lodgement form is available on the
Companys extranet.
Contingency Procedures
When a Tier 1 Framework Participant makes changes to its public keys or contact details, the
Email File Exchange Contacts Lodgement Form must be completed and lodged noting the
changes to contact details and/or attaching new public keys. Tier 1 Framework Participants will
be advised of changes to the database by CS2 operational memorandum.
The Email File Exchange Contacts Lodgement Form (as set out in Appendix M2) is used for
lodging or amending public keys or contact details which effect only Tier 1 Framework
Participants.
The next page is 11.1
PART 11
Fraudulent Items
11.1
Tier 1 Framework Participants must ensure that their systems and procedures give adequate
protection in regard to fraud in connection with Items. Tier 1 Framework Participants may
return an Item or resort to the dispute resolution process specified in Regulation 13 to resolve
any situation with regard to a fraudulent Item.
Clause 11.2 is Confidential
PART 12
DE File Specifications
DE FILE SPECIFICATIONS
Overview
12.1
The DE File Specifications cover the format for electronic exchanges of Files (including Files
containing Record Type 1 Items issued by Users, Return Files, Refusal Files and Reversal Files)
between Framework Participants. All Files exchanged between Framework Participants must
conform with these specifications.
Last amended
effective 4/8/2000
The DE File User Item Specifications cover the normal electronic exchange of Users Record
Type 1 Credit Items and Debit Items (detailed in Appendix C1), electronic return of those Users
Items (detailed in Appendix C2), electronic Refusal of Returned Items (detailed in Appendix
C3) and electronic Reversal of duplicated Items (detailed in Appendix C5). The format is the
same regardless of whether the Sending Member uses normal electronic transmission or, if
exchanges are done under Contingency Procedures.
Last amended
Effective 25/5/07
Items and Files not conforming with the applicable DE File Specifications may be rejected by
Receiving Members in accordance with clauses 8.1 and 8.2.
Nothing in this clause 12.1 prevents a Sending Member accepting non-standard data (which does
not conform with the applicable DE File Specifications) from a User or Bureau or a Lodgement
FI, and converting it to the required format for exchange.
12.2
(a)
Descriptive Record (Record Type 0) : Except for minor variations in some Field
Descriptions, this record type is common to all Files (including Files containing Record
Type 1 Items issued by Users, Return Files, Refusal Files and Reversal Files).
Last amended
effective 4/8/2000
(b)
Detail Record Type 1 : this Record Type is used for both Credit Items and Debit Items
issued by a User and credit and debit Reversing Items and contains the required details to
enable posting to Customers accounts at the Ledger FI.
Last amended
effective 4/8/2000
(c)
Detail Record Type 2 : this Record Type is used by the Ledger FI to electronically return
a Users (Record Type 1) Item to the Trace Record Institution if that Item cannot be
applied.
Last amended
Effective 25/5/07
(d)
Detail Record Type 3 : this Record Type is used when the financial institution holding the
Trace Record account is not prepared to accept a Returned Item and sends it back
electronically to the Ledger FI.
(e)
File Total Record (Record Type 7) is common to all Files (including Files containing
Record Type 1 Items issued by Users, Return Files, Refusal Files and Reversal Files) and
shows the respective totals of Record Type 1, 2 or 3 Items, as applicable, and the net
difference between Credit Items and Debit Items and the totals of each as well as the total
number of these Records on the File.
Last amended
effective 4/8/2000
Files exchanged between Framework Participants are to be in EBCDIC format. Any translation
made to or from the EBCDIC format must ensure that the same characters are represented in
both the source file and the output file and that the characters comply with the BECS Character
Set.
Last amended
effective 26/07/10
DE File Specifications
Structure of File
12.4
Single User
Descriptive
Detail
File Total
(0)
(1)
(7)
Descriptive
Detail
File Total
(0)
(1)
(7)
Descriptive
Detail
File Total
(0)
(1)
(7)
Return/Refusal Files
Descriptive
Detail
File Total
(0)
(2)
(7)
Descriptive
Detail
File Total
(0)
(3)
(7)
Descriptive
Detail
Detail
File Total
(0)
(2)
(3)
(7)
Descriptive
Detail
Detail
File Total
(0)
(3)
(2)
(7)
DE File Specifications
Record Format
12.5
Commonly used terms associated with File formatting, and their meanings, are as follows:
left justified
right justified end input in the last character position of that field.
blank filled
zero filled
unsigned
Descriptive Record,
Detail Record,
Record Type 2
Record Type 3
Last amended
Effective 25/5/07
Framework Participants may publish and disseminate the DE User Item File Specifications to
third parties provided that the column headed "Validation Standard (financial institution use
only)" and the information contained in that column are not included in any such publication.
User Records
Confidential
PART 13
USER RECORDS
(Confidential)
PART 14
Overview
14.1
All Summary Files exchanged between Framework Participants must conform with the
Summary File Specification detailed in Appendix C6.
The format is the same regardless of whether the Sending Member uses normal electronic
transmission or, if exchanges are done under Contingency Procedures.
Summary Files not conforming with the applicable Summary File Specification may be rejected
by Receiving Members.
14.2
(a)
Header Record (Record Type H) : This Record Type is common to all Summary Files.
(b)
Summary Record (Record Type S) : This Record Type contains summary information for
a User as set out in Appendix C6.
(c)
Trailer Record (Record Type T) : This Record Type is common to all Summary Files.
Files exchanged between Framework Participants are to be in EBCDIC format. Any translation
made to or from the EBCDIC format must ensure that the same characters are represented in
both the source file and the output file and that the characters comply with the BECS Character
Set.
Last amended
effective 26/07/10
Record Format
14.5
Commonly used terms associated with File formatting, and their meanings, are as follows:
left justified : start input in the first character position of that field.
right justified : end input in the last character position of that field.
blank filled :
zero filled :
unsigned :
Header Record;
Record Type T
Trailer Record,
Framework Participants may publish and disseminate the Summary File Specification to third
parties provided that the column headed "Validation Standard (financial institution use only)"
and the information contained in that column are not included in any such publication.
DE FILE USER ITEM SPECIFICATIONS - RECORD FORMAT (Validation Standard column Confidential)
Record Type 0 - Descriptive Record
Char
Pos
Field
Size
1
2-18
19-20
Field Description
User Specification
1
17
2
Record Type 0
Blank
Reel Sequence Number
Must be '0'.
Must be blank filled.
Must be numeric commencing at 01.
Right justified. Zero filled.
21-23
24-30
31-56
7
26
Blank
Name of User Supplying File
(User preferred name as advised in
application)
57-62
63-74
12
DE FILE USER ITEM SPECIFICATIONS - RECORD FORMAT (Validation Standard column Confidential)
Record Type 0 - Descriptive Record (Continued)
Char
Pos
Field
Size
75-80
81-120
40
Field Description
User Specification
DE FILE USER ITEM SPECIFICATIONS - RECORD FORMAT (Validation Standard column Confidential)
Record Type 1 - Detail Record
Char
Pos
Field
Size
Field Description
User Specification
1
2-8
1
7
Record Type 1
BSB Number
Must be '1'.
Must be numeric with a hyphen in character position 5.
Character positions 2 to 4 must be a valid 2 or 3 digit Institution
Identifier issued by APCA. (Refer to APCA publication BSB
Numbers in Australia).
9-17
18
Indicator
DE FILE USER ITEM SPECIFICATIONS - RECORD FORMAT (Validation Standard column Confidential)
Record Type 1 - Detail Record (Continued)
Char
Pos
Field
Size
19-20
Field Description
User Specification
Transaction Code
21-30
10
Amount
31-62
32
63-80
18
Lodgement Reference
Reference as submitted by the User,
indicating details of the origin of the
entry, eg., Payroll Number, Invoice,
Contract Number.
Note:
This field is used by Financial
Institutions for statement narrative.
81-96
16
Trace Record
The BSB Number and account number to
which an Item (including any Record
Type 1 Item issued by any User, any
Returned Item, any Refused Item and
any Reversing Item) must be returned if
it cannot be applied1.
Continued next page.
Note: In many cases the Trace Record is also used to satisfy the requirements of the Anti-Money Laundering and Counter-Terrorism Financing Act 2006 (Cth) concerning the inclusion of Tracing Information
in electronic funds transfer instructions. Please refer to Part 5 of the Act for details.
DE FILE USER ITEM SPECIFICATIONS - RECORD FORMAT (Validation Standard column Confidential)
Record Type 1 - Detail Record (Continued)
Char
Pos
Field
Size
(81-87)
Field Description
User Specification
(88-96)
(Account Number)
97-112
16
Name of Remitter
(Name of originator of the entry. This
may vary from Name of User).
Full BECS character set valid. Must not contain all blanks.
Left justified. Blank filled.
Note:
This field is used by Financial
Institutions for statement narrative.
When a Detail Record is used for a
Financial Institution drawing under a
TNA, this field must contain the name
of the Lodgement Financial Institution.
113-120
Note:
DE FILE USER ITEM SPECIFICATIONS - RECORD FORMAT (Validation Standard column Confidential)
Record Type 7 - File Total Record
Char
Pos
Field
Size
1
2-8
9-20
21-30
Field Description
User Specification
1
7
12
10
Record Type 7
BSB Number
Blank
File (User) Net Total Amount
31-40
10
41-50
10
51-74
75-80
24
6
Blank
File (User) Count of Record Type 1
Must be '7'.
Must be 999-999.
Must be blank filled.
Numeric only valid. Show in cents without punctuation.
Right justified. Zero filled. Unsigned.
Numeric only valid. Show in cents without punctuation.
Right justified. Zero filled. Unsigned.
Numeric only valid. Show in cents without punctuation.
Right justified. Zero filled. Unsigned.
Must be blank filled.
Numeric only valid. Right justified. Zero filled.
DE FILE USER ITEM SPECIFICATIONS - RECORD FORMAT (Validation Standard column Confidential)
Record Type 7 - File Total Record (Continued)
Char
Pos
Field
Size
81-120
40
Note:
Field Description
User Specification
Blank
Description
Numeric
0 to 9
Alphabetic
Special Characters
+
@
SP
$
!
%
&
(
)
*
.
/
#
=
:
;
?
,
[
]
_
^
Plus sign
Minus sign or hyphen
At sign
Space
Dollar sign
Exclamation mark
Percentage sign
Ampersand
Left Parenthesis
Right Parenthesis
Asterik
Period or decimal point
Solidus (slash)
Number Sign (Pound or Hash)
Equal Sign
Colon
Semicolon
Question mark
Comma
Apostrophe
Left square bracket
Right square bracket
Low line (underscore)
Circumflex
Specified Locations
Deleted
effective 28/10/96
APPENDIX D
[deleted]
Appendix E:
Deleted
effective 28/10/96
APPENDIX E
[deleted]
APPENDIX F
Confidential
APPENDIX G1
RETURNING/REFUSING FI ID NUMBERS
AND REVERSING FI ID NUMBERS
APPENDIX G2
DIRECT DEBIT REQUEST
CLAIMING FINANCIAL INSTITUTION
IDENTIFICATION NUMBERS
APPENDICES G1 & G2 ARE LOCATED SEPARATELY
Deleted
Effective 31/3/2000
APPENDIX H
LEDGER FI REQUIRING PD-C LISTS
[Deleted]
Section 1
Executive Summary
Section 2
Section 3
Communications
Section 4
Contingency Procedures
Section 5
Disabling Events
I1.1
1.
EXECUTIVE SUMMARY
1.1
Overview
These guidelines have been prepared and endorsed by the Management Committee. They are
not mandatory rules but intended to guide the Tier 1 Framework Participants when exercising
discretion to determine what action is to be taken in response to a Disabling Event.
Each Disabling Event should be treated on its merits.
1.2
Settlement
Unless specifically deferred, settlement will not be affected by the occurrence of a Disabling
Event. Settlement will always be effected on the exchange balances.
1.3
Last amended
effective 21/05/12
Interest
As covered in Part 9, clause 9.2F, interest will be payable (as normal) on any exchanged Item
in respect of which, settlement is effected later than the day on which that Item is exchanged
for value.
Last amended
effective 21/05/12
Debit Items
Where a Disabling Event occurs and other Tier 1 Framework Participants are asked, by a
Disabled Framework Participant, to hold Debit Files that would have been exchanged in those
other Members outward exchanges if not for a Disabling Event, those held Debit Files should
retain the original PD-Day. When those Files are actually exchanged, interest will be payable
by the Disabled Framework Participant from the PD-Day until the date settlement of those
Debit Items is effected.
No interest is payable with respect to any Debit Items held unexchanged by a Disabled
Framework Participant where the Disabled Framework Participant holds the Items because of
a Disabling Event affecting its outward exchanges.
Credit Items
Where a Disabling Event occurs and other Tier 1 Framework Participants are asked, by a
Disabled Framework Participant, to hold Credit Items that would have been exchanged in
those other Members outward exchanges if not for a Disabling Event, no interest will be
payable to the Disabled Framework Participant.
No interest is payable with respect to any Credit Items held unexchanged by a Disabled
Framework Participant where the Disabled Framework Participant holds the Items because of
a Disabling Event affecting its outward exchanges.
I1.2
2.
2.1
2.2
to provide support and recommend appropriate actions to be taken by the Disabled Tier 1
Framework Participant and impacted Framework Participants; and
Framework Participants
The roles and responsibilities of Framework Participants in relation to a Disabling Event are as
follows:
to ensure that their internal contingency plans are consistent with these industry
Contingency Procedures (Part 10);
communicate directly with their customers, the Company and other relevant parties.
I2.1
COMMUNICATIONS
3.1
This section defines the communications process between the Company and Tier 1 Framework
Participants in the event of a Disabling Event.
3.2
3.3
3.4
I3.1
4.1
4.2
receive and record PDN from the Disabled Tier 1 Framework Participant;
1
2
actively pursue the identification and appropriate resolution of problem causing the
Disabling Event;
invoke the appropriate internal contingency plans which may include invoking the
Contingency Procedures set out in the BECS Procedures (Part 10) and Appendix I;
notify the Company of the internal assessment that a Disabling Event may directly or
indirectly impact other Framework Participants by completing a PDN (Appendix J);
consider and take appropriate action on the advice and recommendations given by the
Company regarding the Disabling Event, if appropriate; and
keep the Company updated of any change concerning the Disabling Event by
completing and forwarding subsequent PDNs at two (2) hourly intervals, or more
frequently if appropriate, during business hours2.
I4.1
DISABLING EVENTS
5.1
Overview
This section describes each identified Disabling Event that may occur and appropriate actions
that the Company and Tier 1 Framework Participants may undertake to address them. Each
Disabling Event covered is categorised.
5.2
Disabling Events
There are three (3) categories of event that may result in a Disabling Event:
Last amended
effective 21/05/12
Each of these categories only results in a Disabling Event if it affects, or may affect, the ability
of a Framework Participant to participate to the normal and usual extent in exchanges of Items
(including Record Type 1 Items issued by any User, Returned Items, Refusal Items and
Reversing Items).
I5.1
Disabling Event Description: Tier 1 Framework Participant(s) unable to send or receive Direct Entry (DE) files to other Tier 1 Framework Participants using primary exchange arrangements.
EXTENT OF THE
DISABLING EVENT
Reported by a Tier 1
Framework
Participant
where Primary Exchange
Arrangement has failed.
arrange a later transmission after the problem is fixed agreed bilaterally with other Tier 1 Framework
Participants;
complete a Contingency File Exchange Form (as set out in Appendix M1) and forward to the receiving
Tier 1 Framework Participant;
Reported by a Tier 1
Framework Participant that
they
have
failed
to
exchange DE files with
another Tier 1 Framework
Participant
using
Contingency
Exchange
Arrangements,
assuming
that the Primary Exchange
Arrangement failure has
already been reported.
1
2
broadcast regular PDN advice to the Company, during business hours2, until Disabling Event resolved.
arrange a later transmission after the problem is fixed agreed bilaterally with other Tier 1 Framework
Participants;
complete a Contingency File Exchange Form (as set out in Appendix M1) and forward to the receiving
Tier 1 Framework Participant;
exchange files using other bilaterally agreed Contingency Exchange arrangements as tabled in Appendix
L Contingency Exchange Arrangements Matrix;
broadcast regular PDN advice to the Company, during business hours2, until Disabling Event resolved.
Agreed bilaterally
Monday to Friday, 8.30am to 5.30pm
I5.2
EXTENT OF THE
DISABLING EVENT
Reported by any Framework Participant that they are
unable to process DE data internally
1
2
delay exchange pending resolution of the problem if problem relates to electronic files received - agreed
bilaterally with other Tier 1 Framework Participants;
broadcast PDN
Participants;
broadcast regular PDN to the Company, during business hours2 until Disabling Event resolved.
to
all
Framework
Agreed bilaterally
Monday to Friday, 8.30am to 5.30pm
I5.3
5.2.3
Disabling Situation/Event Description: Tier 1 Framework Participant unable to provide settlement data
EXTENT OF THE
DISABLING EVENT
Reported by a Tier 1
Framework Participant that
they are unable to provide
File Settlement Instructions
with respect to Direct Entry
files sent for the business
day.
Agreed bilaterally
I5.4
APPENDIX J1
APCS AND BECS PROCESSING DIFFICULTY NOTIFICATION
DETAILS
Date of Advice:
DD
MMM
YYYY
Notifying Institution:
Institution Experiencing Difficulty:
CONTACT POINT
`
Name:
Phone Number:
Fax Number:
Email Address:
J1.1
MMM
YYYY
(Approximate)
Date of Availability:
DD
MMM
YYYY
COMMENTS
ATTACHMENTS
J1.2
APPENDIX J2
BECS PROCESSING DIFFICULTY NOTIFICATION
DETAILS
Date of Advice:
DD
MMM
YYYY
Notifying Institution:
Institution Experiencing Difficulty:
CONTACT POINT
Name:
Phone Number:
Fax Number:
Email Address:
J2.1
MMM
Time of Availability:
YYYY
(Approximate)
Date of Availability:
DD
MMM
YYYY
COMMENTS
ATTACHMENTS
J2.2
K1.1
L1.1
CONFIDENTIAL COMMUNICATION:
This communication is confidential and intended only for the use of the addressee. If you have received this communication in error, please notify the financial institution from which you
have received it, at the telephone number given, to arrange disposal. Unauthorised use of the information in this message may result in legal proceedings against the user. Thank you.
To:
Fax number:
Email:
Please refer to the email file exchange contacts database for details of Receiving Members facsimile number / email address.
[Full Name & ACN/ARBN/ABN of Sending
Framework Participant]
From:
Fax number:
Email:
Authorised Contact:
(Name & position)
Signature:
We advise that due to a Disabling Event we are experiencing a partial/total loss of our ability to send/receive DE files using our
primary exchange arrangements. We seek your assistance in sending/receiving our files as detailed below.
Sending
Filename:
File size :
Number of Items in file:
Type of items in file:
Total Value of file:
Debits
Credits
Contact
Phone:
2
3
Contact
Phone:
Specifically, the Procedures documents require each Tier 1 Framework Participant to test its contingency
exchange arrangement:
at least once each calendar half year, over a period of time that is no more than four calendar years
apart,
using live data, and data received must be used to process actual live transactions.
Tests to be done each calendar half year should be with partners, to be arranged bilaterally. Framework
Participants choosing to use physical medium for contingency exchange must test each bilateral
arrangement at least once every calendar half year, until such physical medium is replaced with alternate
electronic communication.
After every test of contingency exchange arrangements, each Tier 1 Framework Participant is required to:
confirm or amend the contact details held on APCA's Email File Exchange Contacts Database.
__________________________________________________________________
Institution _____________________________________________________________________________
(Tier 1 Framework Participant)
ABN/ARBN/ACN:
__________________________________________________________________
Please complete and return before [ Insert date ] to
APCA Operations
Australian Payments Clearing Association Limited
Fax: (02) 9221 8057
Email: <operations@apca.com.au>
Has completed its bilateral testing of contingency exchange arrangement(s) in the Framework(s) specified
below, with at least one Tier 1 Framework Participants (test partner) as indicated.
Our contingency exchange arrangements for the Framework(s) (indicated above) have been
successfully tested and comply with the industry standards outlined (as appropriate) in:
BECS Procedures, Part 10, clauses 10.10 to 10.13.
OR
We advise that our details held on APCAs Email File Exchange Contacts Database are not up-to-date.
The correct details are shown below. We also confirm that we have posted the correct details directly to
the relevant Email File Exchange Contacts Database on the APCA Extranet.
Fax number
AUTHORISED SIGNATORY
Name of person signing Certificate
Position
Signature
Date
- END -