General Outline of the Standard
1. The Superannuation Data and Payment Standards 2012 (the Standard) is made under subsection 34K(3) of the Superannuation Industry (Supervision) Act 1993 (SISA 1993).
2. The Standard establishes the superannuation data and payment standards relating to superannuation data and payment matters for the purposes of the SISA 1993.
3. The Standard is a legislative instrument for the purposes of the Legislative Instruments Act 2003 (LIA 2003).
Date of effect
4. The Standard commences on the day after its registration on the Federal Register of Legislative Instruments under the LIA 2003.
What is this Standard about?
5. The Standard specifies the minimum requirements for dealing with payments and information relating to certain transactions within the superannuation system including employer contributions, rollovers and transfers between superannuation entities and associated reporting obligations for superannuation purposes.
6. The purpose of establishing the Standard is to further the interests of beneficiaries of superannuation entities by improving the efficiency and productivity of the superannuation system as a whole.
What is the effect of the Standard?
7. Broadly, the Standard establishes system requirements that must be adhered to by:
§ trustees of superannuation entities in relation to rollover and transfer transactions, contributions and associated payments; and
§ employers in relation to contributions and associated payments.
8. By dealing with payments and information in the manner specified in the Standard, trustees and employers will be complying with the Standard and thus complying with their obligations under Part 3B of the SISA 1993 (as relevant to trustees of superannuation entities and employers).
Who is covered by the Standard
Rollover and transfer transactions and associated payments
9. In relation to rollover and transfer transactions and the associated payments, the Standard applies to trustees of superannuation entities regulated by APRA other than pooled superannuation trusts (PSTs) (APRA-regulated superannuation entities).
10. The requirements prescribed by the Standard for such transactions apply to an entity from 1 July 2013 in relation to conduct that occurs on or after that date.
11. However, compliance with the Standard is subject to the transitional rules as set out in Schedule 1 to the Standard. An entity complies with the Standard in relation to rollover and transfer transactions and the associated payments during the transitional period if the entity complies to the extent it is required to comply under Schedule 1 to the Standard.
12. The requirements in relation to rollover and transfer transactions and the associated payments do not apply to trustees of SMSFs.
An entity with a closed product
13. The Standard does not apply to an APRA-regulated superannuation entity in relation to a closed product. A closed product for the purposes of clause 6 of the Standard means a product that does not receive any contributions or rollovers, whether from an existing member or any other person, but that may rollover or transfer a member’s withdrawal benefit to another superannuation entity.
Contribution transactions and associated payments
14. In relation to contribution transactions and associated payments, the Standard applies to:
§ trustees of APRA-regulated superannuation entities;
§ trustees of self managed superannuation funds (SMSFs) that receive contributions from employers that are not related parties of the SMSF; and
§ employers making contributions to superannuation funds, unless the employer only makes contributions to an SMSF of which the employer is a related party.
15. The requirements prescribed by the Standard for such transactions apply from:
§ 1 July 2014 - for trustees of APRA-regulated superannuation entities; trustees of SMSFs (that is, in relation to contributions from employers if the employer is not a related party of the SMSF); and medium to large employers (20 or more employees);
§ 1 July 2015 (unless a later date is prescribed in the SISR 1994) – for small employers (less than 20 employees).
16. However, compliance with the Standard is subject to the transitional rules as set out in Schedule 1 to the Standard. An entity complies with the Standard in relation to contribution transactions and associated payments during the transitional period if the entity complies to the extent it is required to comply under Schedule 1 to the Standard.
The Standard comprises documents incorporated by reference
17. The Standard incorporates by reference documents as they exist from time to time, including further documents or website content referenced in such documents.
18. Compliance with the Standard requires compliance with the specifications and requirements in those documents to the extent that they are relevant to the particular transaction.
19. The documents referred to in Schedules 1 through 6 to the Standard are published by the Commissioner of Taxation and are available on the Australian Taxation Office (ATO) website www.ato.gov.au.
Updating of documents incorporated by reference in Schedules 1 through 6 to the Standard
20. It is essential that the documents incorporated by reference in the Schedules to the Standard are able to be updated from time to time to ensure the Standard takes into account advancements in technology that will support greater efficiency and productivity across the superannuation industry. It may also be necessary to refine the requirements in the documents referred to in the Schedules to the Standard in response to ongoing industry consultation and governance.
21. Any changes to specifications and requirements in the documents referred to in the Schedules to the Standard will only occur after appropriate industry consultation.
22. The version, the release date and the date the document applies from will be included on the front page of the document when published. The document will also contain a version control table.
23. Updates to any of the documents incorporated by reference in the Schedules to this Standard will be made available on the ATO website once finalised following consultation.
Compliance cost impacts
24. Compliance cost impacts in relation to superannuation data and payment standards were considered in the Regulation Impact Statement, Stronger Super, September 2011 (section 2, SuperStream), which is available at www.ris.finance.gov.au.
25. This Standard, which is part of a statutory framework, is consistent with the option recommended in the Regulation Impact Statement to mandate data and e-commerce standards within the Standard Business Reporting (SBR) framework to maximise efficiencies and provide a level playing field for participants.
Background
26. The underlying object of establishing the Standard is to enhance beneficiaries’ superannuation interests by increasing efficiency in relation to core transactions such as contributions and rollovers and transfers across the superannuation industry.
27. As noted in the Stronger Super Information Pack published on 21 September 2011:
The adoption of data and e‑commerce standards will have substantial benefits for all participants and will enable participants to communicate by using standardised business terms, while electronic transmission will allow for a more automated and timely processing of transactions with fewer errors. This will result in improved efficiency, an easier system for employers to use, fewer lost accounts and more timely flow of money to member accounts.
28. Achieving this objective requires the specific information technology (IT) parameters of core transactions such as contributions and rollovers and transfers to be defined.
29. The most efficient way for this detail to be available to all relevant stakeholders is by way of documents incorporated by reference in the Schedules to the Standard.
30. These documents contain mandatory requirements and specifications that must be complied with in order for particular transactions to conform with the Standard.
31. Existing web-based portals supporting electronic payment and receipt of employer contributions will continue to be acceptable under the Standard if, and only if, they meet the requirements regarding alternate arrangements for contributions as specified in the Data and Payment Standards - Contributions Message Implementation Guide document referred to in Schedule 4(a) to the Standard.
32. Employers and trustees of superannuation entities that choose to maintain existing electronic employer contribution lodgement arrangements must be able to demonstrate that the arrangements conform with the requirements regarding alternate arrangements for contributions in the Data and Payment Standards - Contributions Message Implementation Guide outlined in Schedule 4(a) to the Standard.
Specific issues
Superannuation Guarantee (SG) Implications
33. Employers should note that their obligations under the Superannuation Guarantee Administration Act 1992 (SGAA 1992) are not altered by the Standard.
34. Employers need to ensure that minimum data requirements as specified in the documents referred to in the Schedules to the Standard are provided with a contribution to enable the superannuation entity to readily allocate the contribution to the relevant account for the benefit of the relevant individual. Employer contributions may be refunded to an employer if they cannot be allocated for the benefit of a particular individual.
35. Contribution payments must also be made electronically in accordance with requirements specified in the Data and Payment Standards - Payment Methods document referred to in Schedule 3 to the Standard.
36. Failure to meet the requirements specified in the Standard may result in a penalty under Part 3B of the SISA 1993.
Interaction with approved form requirements
37. The Standard will apply to certain reporting obligations that apply to trustees of superannuation entities including the rollover benefit statement. Trustees of superannuation entities must satisfy any applicable requirements under the Standard in relation to such reporting obligations.
Prescribed transport and authentication standards
38. The Standard prescribes minimum requirements that must be complied with for message transmission and authentication. These minimum requirements are based primarily on widely adopted open-source messaging protocols.
39. Specifically, the message packaging requirements prescribed for the purposes of the Standard are based on the international standard OASIS ebXML Messaging Services Version 3.0: Part 1, Core Features, OASIS Standard, 1 October 2007 (‘ebMS 3.0 Messaging Standard’).
40. The conformance profiles defined for the purposes of the Standard are based on the AS4 Profile of ebMS 3.0 Version 1.0, Candidate OASIS Standard 013, 17 August 2012 (‘AS4 Profile’).
41. The e-commerce solution applied by a particular entity in order to comply with the Standard, that is, the specific technology platform or network used by a trustee of a superannuation entity or employer, will continue to be determined by industry.
42. However, the e-commerce solution adopted by an entity will need to align with the requirements of the ‘profile’ adopted by the entity as set out in the Data and Payment Standards - Message Orchestration and Profiles document referred to in Schedule 5 to the Standard.
Penalties for non-compliance
43. Trustees of superannuation entities and employers are required to comply with the Standard to the extent that the Standard is applicable to them. Failure to comply may result in:
§ the issue of an infringement notice to the trustee of an APRA-regulated superannuation entity;
§ an administrative penalty imposed on the trustee of an SMSF or an employer.
44. Consistent with certain other contraventions of the SISA 1993 non-compliance with the Standard also constitutes a strict liability offence. The maximum penalty that may be imposed upon conviction is 20 penalty units.
45. The Regulator is also able to give trustees of superannuation entities and employers a direction requiring them to address a contravention of the Standard or to take action to avoid contravening the Standard.
Consultation
46. Subsection 34K(9) of the SISA 1993 requires the Commissioner of Taxation (the Commissioner) to consult with the Australian Prudential Regulation Authority (APRA) in preparing the Standard.
47. The Commissioner has engaged in direct consultation with APRA on a regular basis as the framework for the Standard has been developed.
48. The Commissioner has also consulted extensively with a range of industry stakeholders when developing the Standard, the transitional rules in Schedule 1 to the Standard and the documents that are included by reference in each of the Schedules to the Standard. Consultation occurred in a range of forums including the SuperStream Working Group which is comprised of 28 members who have been nominated to represent key stakeholders across the superannuation industry.
49. The Commissioner is satisfied that such consultation as is appropriate and reasonably practicable has been undertaken and that all legal and other requirements have been met during the development of the Standard.
Governance
50. Primary governance responsibility for the Standard rests with the Commissioner.
51. To the extent that the Standard incorporates the SBR taxonomy (definitional and reporting), specific approvals for the changes must be provided by the SBR Program Board or its delegate committees.
52. The Super Stream Advisory Council has the express task of providing an open forum for input from stakeholders and advising on the implementation, maintenance and recommended changes to the system requirements and specifications in the documents incorporated by reference in the Schedules to the Standard. The Super Stream Advisory Council has a significant ongoing role in terms of monitoring the success of the requirements and specifications included in the Standard and recommending refinements and improvements where appropriate.
Exemption from disallowance and sunsetting regime
53. A Standard made under subsection 34K(3) of the SISA 1993 is not a disallowable legislative instrument.
54. Section 42 of the LIA 2003 provides for the disallowance of legislative instruments. However, subsection 44(2) of the LIA 2003 provides that section 42 does not apply to, among other things, instruments (other than regulations) relating to superannuation. As a result, the Standard is not a disallowable legislative instrument under section 42 of the LIA 2003.
55. The sunsetting regime contained in Part 6 of the LIA 2003 also does not apply to the Standard. Item 42 of the table contained in subsection 54(2) of the LIA 2003 provides that Part 6 of the LIA 2003 does not apply to any legislative instrument (other than regulations) relating to superannuation.
Statement of compatibility with human rights
56. As noted above, this Standard is not a disallowable legislative instrument under section 42 of the LIA 2003. Consequently a statement of compatibility with human rights is not required under subsection 9(1) of the Human Rights (Parliamentary Scrutiny) Act 2011.
Michael D’Ascenzo
Commissioner of Taxation
24 December 2012
Legislative references:
Legislative Instruments Act 2003
Human Rights (Parliamentary Scrutiny) Act 2011
Superannuation Industry (Supervision) Act 1993
Superannuation Industry (Supervision) Regulations 1994
Taxation Administration Act 1953
ATTACHMENT 1 – THE SCHEDULES TO THE STANDARD
57. The documents incorporated by reference in the Schedules to the Standard form the operational part of the Standard. While each document sets out the specifications and requirements of a component of the Standard, these components are linked and therefore the documents must be read together and applied as one to ensure all the requirements of the Standard in relation to a transaction are met.
Schedule 1 Transitional arrangements
58. Schedule 1 sets out acceptable transitional arrangements in relation to rollovers and transfers and contributions.
59. The orderly transition towards full compliance with the Standard is an important part of ensuring employers, and trustees of superannuation entities are able to progressively implement requirements under the Standard in a manner that ensures confidence in, and integrity of, the superannuation system during this period of significant change.
Rollover transitional arrangements
60. The Standard applies to a trustee of an APRA-regulated superannuation entity in respect of rollovers and transfers (subsequently referred to as ‘rollovers’) from 1 July 2013.
61. The documents incorporated by reference in Schedules 3, 4(b), 5 and 6 to the Standard set out certain requirements in relation to rollover transaction messages, rollover initiation messages and associated electronic payments (transactions) that must be met for an entity to comply with the superannuation data and payment standards. To allow a trustee time to conform with those requirements, Schedule 1 to the Standard specifies what a trustee must do by a particular date (typically this date will be on or before 31 December 2013) to comply with the superannuation data and payment standards.
62. The rollover transition-in period is the period from 1 July 2013 to 31 December 2013 inclusive. By no later than 31 December 2013, all APRA-regulated superannuation entities will be required to have transitioned to full compliance with the Standard for rollover transaction messages, rollover initiation messages and associated electronic payments, unless a trustee has a notice in writing from APRA adjusting the transition in completion date to an alternative date (alternative transition-in completion date) that is after 31 December 2013.
Transition-in completion date
63. An APRA-regulated superannuation entity is required to work out its transition-in completion date.
64. The entity’s transition-in completion date is determined by reference to the entity’s total value of rollover transactions, both inbound and outbound, (total rollover value) as reported in Table 8: Fund level data 2011 in APRA’s Superannuation Fund-level Profiles and Financial Performance (the Table 8 document), which issued on 29 February 2012 and is available at www.apra.gov.au.
65. If an entity has both an inward rollover amount and an outward rollover amount reported in the Table 8 document, the entity’s total rollover value is the sum of those two amounts. If, however, an entity has only one of those amounts reported in the Table 8 document, it is that amount that is the entity’s total rollover value amount. If an entity does not have either amount reported in the Table 8 document, the entity has a total rollover value of zero.
66. This approach, which focuses on rollover transactions processed, provides a measurable variable by which entities and the Regulator will be able to determine when the obligation to fully comply with the Standard arises.
67. The rollover value range (Column 2 of Table 1 in clause 2.2.1 of Schedule 1 to the Standard) that the entity’s total rollover value falls within determines the Transition-In Completion Date (Column 3) for that entity and also the band (Column 1) applicable to that entity.
68. The transition-in completion date along with the applicable band is relevant to the entity’s compliance with the specifications and requirements in clause 2.3 of Schedule 1 to the Standard. An entity may, however, transition to compliance with a particular requirement, or to full compliance with the Standard, by a date earlier than the entity’s transition-in completion date or the date specified in a particular clause. For example, an entity that is within band 1, 2 or 3, may choose to comply with the requirements under clause 2.3.4 before 5 October 2013.
Alternative transition-in completion date
69. If a request is made by an APRA-regulated superannuation entity, APRA may, by notice in writing to the trustee of an APRA-regulated superannuation entity, adjust the entity’s transition-in completion date to an alternative date (alternative transition-in completion date). The decision whether to adjust the transition-in completion date of an entity is at APRA’s discretion.
70. An alternative transition-in completion date may apply for all or part of the operations of the APRA-regulated superannuation entity and to that extent it will apply to that entity instead of the transition-in completion date worked out under clause 2.2.1 of Schedule 1 to the Standard.
71. If an alternative transition-in completion date is relevant to only part of the entity’s operation the transition-in completion date (as worked out under clause 2.2.1 of Schedule 1 to the Standard) will continue to apply with respect to other parts of the entity’s operation.
72. The alternative transition-in completion date may be a date that is within the rollover transition-in period and could potentially be a date that is earlier than the date by which the entity is otherwise required to comply with a transitional requirement. For example, an entity in band 1 may seek an alternative transition-in completion date that is later than 6 September 2013 but before 5 October 2013 (which would otherwise be the date by which the entity must comply with clause 2.3.4 of Schedule 1 to the Standard).
73. In exceptional circumstances, such as major legacy system transformation projects which are planned to deliver sustainable member benefits at a later date, APRA may determine an alternative transition-in date that is after 31 December 2013.
74. However, notwithstanding an alternative transition-in completion date and whether it applies to part or all of an entity’s operations, the band that is relevant to that entity remains the band as worked out under clause 2.2.1 of Schedule 1 to the Standard.
Temporary entry level profile
75. The transitional arrangements include a temporary entry level profile (being a message exchange arrangement but which does not define the content of the message).
76. The temporary entry level profile sets out the minimum conditions that a trustee of an APRA-regulated superannuation entity must meet to comply with the Standard.
77. The temporary entry level profile and a default agreement for that profile is included by reference in Schedule 1 to the document Data and Payment Standards - Temporary Entry Level Profile and Default Agreement.
Rollover transaction messages (clauses 2.3.1 to 2.3.3)
78. The trustee of an APRA-regulated superannuation entity must meet the minimum conditions under the temporary entry level profile in relation to receiving rollover transaction messages. These minimum conditions apply from 1 July 2013 up to and including the entity’s transition-in completion date or, if relevant, the entity’s alternative transition-in completion date. Following the transition‑in period, in relation to rollover transaction messages the entity must operate a profile in accordance with the specifications and requirements set out in the Data and Payment Standards - Message Orchestration and Profiles document referred to in Schedule 5 to the Standard.
79. The trustee of an APRA-regulated superannuation entity must:
§ maintain a capability to receive rollover transaction messages and associated electronic payments that fully comply with the relevant specifications and requirements contained in the documents referred to in Schedules 3, 4(b), 5 and 6 to the Standard from 1 July 2013; and
§ send rollover transaction messages and associated electronic payments that fully comply with the relevant specifications and requirements contained in the documents referred to in Schedules 3, 4(b), 5 and 6 to the Standard from the day immediately after the entity’s transition-in completion date or, if relevant, the day immediately after the entity’s alternative transition-in completion date.
Rollover initiation messages (clauses 2.3.4 to 2.3.7)
80. A rollover initiation message is the data message that initiates a rollover transaction.
81. The temporary entry level profile for rollover initiation messages is relevant to:
§ an APRA-regulated superannuation entity that falls within bands 4 to 8. In this case, the entity must meet the minimum conditions under the temporary entry level profile in relation to receiving rollover initiation messages from 5 October 2013 up to and including the entity’s transition-in completion date or, if relevant, up to and including the entity’s alternative transition-in completion date.
§ an APRA-regulated superannuation entity that falls within bands 1 to 3 and that has an alternative transition-in completion date that is later than 5 October 2013. In this case, the entity must meet the minimum conditions under the temporary entry level profile in relation to receiving rollover initiation messages from 5 October 2013 up to and including the entity’s alternative transition-in completion date.
82. Following the transition‑in period, in relation to rollover initiation messages the entity must operate a profile in accordance with the specifications and requirements set out in the Data and Payment Standards - Message Orchestration and Profiles document referred to in Schedule 5 to the Standard. If an APRA-regulated superannuation entity is within band 1, 2, or 3 and does not have an Alternative Transition-In Completion Date that is later than 5 October 2013, that entity in relation to rollover initiation messages must operate a profile in accordance with the specifications and requirements set out in the Data and Payment Standards - Message Orchestration and Profiles document referred to in Schedule 5 to the Standard from 5 October 2013.
83. The trustee of an APRA-regulated superannuation entity that falls within bands 4 to 8 must:
§ maintain a capability to receive rollover initiation messages that fully comply with the relevant specifications and requirements contained in the documents referred to in Schedules 4(b), 5 and 6 to the Standard from 5 October 2013 or, if relevant, from the day immediately after the entity’s alternative transition-in completion date;
§ send rollover initiation messages that fully comply with the relevant specifications and requirements contained in the documents referred to in Schedules 4(b), 5 and 6 to the Standard from the day immediately after the entity’s transition-in completion date or, if relevant, from the day immediately after the entity’s alternative transition-in completion date.
Compliance – one or both parties enabled to conform with the Standard
84. Where both parties to a rollover transaction are fully enabled to transact in full compliance with the Standard in terms of sending and receiving rollover transaction messages, the transferring provider will be taken to have satisfied its obligations under paragraph 390-10(2)(a) of Schedule 1 to the TAA 1953 by providing a compliant rollover transaction message to the receiving fund.
85. Where one or both parties to a rollover transaction are not fully enabled to transact in full compliance with the Standard, a transferring provider’s obligations under paragraph 390‑10(2)(a) of Schedule 1 to the TAA 1953 continue to be satisfied using the relevant approved form. For example, this might occur if a rollover transaction involved:
§ an APRA-regulated superannuation fund and an SMSF. While a trustee of an SMSF may choose to comply with the Standard in relation to rollover transactions the trustee of the SMSF is not required to;
§ an APRA-regulated superannuation fund and an exempt public sector superannuation scheme not operating within the Standard; or
§ an entity that had completed the transition-in requirements and an entity that had not yet completed its transition-in requirements as its transition-in completion date had not yet been reached.
86. A transferring superannuation provider will continue to satisfy its reporting obligations to members under paragraph 390-10(2)(b) of Schedule 1 to the TAA 1953 by using the relevant approved form.
From 1 July 2013 and subject to the roll-over transition-in arrangements applying
87. Clause 2.4 of Schedule 1 is subject to the requirements in clause 2.3 of Schedule 1. Clause 2.4 provides that from 1 July 2013 until such time as a trustee of an APRA-regulated superannuation entity is required to comply with clause 2.3.3 (sending compliant rollover transaction messages) and paragraph 2.3.4(b) or clause 2.3.7 (sending compliant rollover initiation messages), trustees of APRA-regulated superannuation entities may continue to:
(a) send rollover transaction messages and make rollover payments in a format that does not conform with the Standard provided all mandatory data elements set out in the Data and Payment Standards – Rollover Message Implementation Guide document referred to in Schedule 4(b) to the Standard are included; and
(b) send rollover initiation messages in a format that does not conform with the Standard provided all mandatory data elements set out in the Data and Payment Standards – Rollover Message Implementation Guide document referred to in Schedule 4(b) to the Standard are included.
Contribution transitional arrangements
88. Contribution transitional arrangements are relevant to entities to which the Data and Payment Standards – Contributions Message Implementation Guide document referred to in Schedule 4(a) to the Standard applies, namely:
§ trustees of APRA-regulated superannuation entities;
§ trustees of SMSFs that receive contributions from employers that are not related parties; and
§ employers making contributions to trustees of superannuation entities, unless they are making a contribution to an SMSF that is a related party.
89. The contribution transition-in period means the period from 1 July 2014 to 30 June 2016 inclusive.
90. The contribution transition-in period is applicable to employers, and trustees of superannuation entities.
91. During the contribution transition-in period alternate electronic file formats may be used by an employer and a trustee of a superannuation entity to process contribution transactions provided certain requirements are met.
92. Those requirements are set out in clause 4.2 of Schedule 1 to the Standard.
93. An alternate electronic file format cannot, however, be used by an employer or trustee of a superannuation entity after 30 June 2016 under the transitional arrangements. At the end of the contribution transition-in period, employers and trustees of superannuation entities to which the Standard applies must conform with all elements of the Standard. (However, in certain limited circumstances as set out in section 8 of the Data and Payment Standards – Contributions Message Implementation Guide alternate arrangements may apply. Conformance with these alternate arrangements means that the entity has complied with the specifications and requirements in that document for the purposes of the Standard.)
Schedule 2 – Terms and Definitions
94. The terms and definitions that apply for the purpose of the documents incorporated by reference in Schedules 3, 4(a), 4(b), 5 and (6) to the Standard are set out in the document Data and Payment Standards - Superannuation Terms and Definitions (the Superannuation Terms and Definitions document) as it exists from time to time.
95. The Superannuation Terms and Definitions document provides consistent terminology to be applied in relation to the Standard, based on established Standard Business Reporting (SBR) Taxonomy (definitional and reporting) (the SBR Definitional Taxonomy).
96. The SBR Definitional Taxonomy is the authoritative technical reference for the detail behind the terms and definitions described in the Superannuation Terms and Definitions document and must be used in conjunction with it. For example, the SBR Definitional Taxonomy will provide additional information about the data types and enumeration values of the defined terms. This information will typically only need to be referenced by a programmer or business analyst when developing, reviewing or testing code for a software implementation.
97. A central component of the terminology applied by the Standard is eXtensible Business Reporting Language (XBRL) which is an open standard mark-up language optimised for business information including, but not limited to, financial and accounting information.
98. The business terms used in superannuation transactions and referenced in the SBR Definitional Taxonomy are defined in the table set out in section 2 of the Superannuation Terms and Definitions document. A business term is a term referenced in the superannuation taxonomy and used to describe a field in a superannuation transaction.
99. For each business term, the table sets out:
§ a plain English definition taken from the SBR Definitional Taxonomy;
§ the data element name that corresponds to the business term;
§ a legal reference (where relevant);
§ a unique reference ID which is the reference number assigned to that business term in the SBR Definitional Taxonomy; and
§ a version number which identifies the version reference within the SBR Definitional Taxonomy.
100. The Superannuation Terms and Definitions document, as with other documents incorporated in Schedules 3, 4(a), 4(b), 5 and 6 to the Standard, specifies the meaning of certain key words by reference to a further document (RFC 2119).
101. Specifications and requirements in the documents incorporated in the Schedules to the Standard are expressed in terms of those key words and thus an entity conforms with the Standard in relation to such specifications or requirements if its actions are consistent with the meaning given to those key words as set out in the RFC 2119 document as it exists from time to time. If, for example, a specification or requirement is optional an entity conforms with the Standard whether or not it meets or carries out that specification or requirement. Other specifications and requirements are expressed in terms of should or should not and thus are not absolute but require consideration and weighing up before proceeding in a different manner. Specifications and requirements that are expressed in terms of must or must not being an absolute requirement or an absolute prohibition require strict adherence in order to conform with the Standard.
Schedule 3 – Payment Methods
102. The payment methods that must be used by employers and superannuation entities to comply with the Standard are set out in the document Data and Payment Standards - Payment Methods (the Payment Methods document) as it exists from time to time.
Electronic payment methods
103. Acceptable payment options are based on the Bulk Electronic Clearing System (BECS) maintained by the Australian Payment Clearing Association (APCA) and BPAY maintained by BPAY Pty Ltd.
104. An employer must send contribution payments using either the BECS Direct Entry BECS DE) System or BPAY, unless an alternative payment method has been agreed between the employer and the superannuation entity.
105. A trustee of a superannuation entity must be able to send and receive payments electronically using the BECS DE system or, if an employer uses BPAY, using BPAY. A trustee can, however, only use BPAY to send and receive payments electronically when dealing with an employer that uses BPAY. Thus superannuation entities when dealing with each other must use the BECS DE system, unless an alternative payment method has been agreed between the entities.
Alternate payment methods
106. A sending and receiving party can mutually agree to use an alternative electronic payment method (that is, other than the BECS DE system or BPAY) provided that each party otherwise complies with the superannuation data and payments standards.
107. If an alternative payment method is used it must comply with the payment reference number requirements set out in section 2.2 of the Payment Methods document.
The payment reference number requirements
108. The Payment Methods document prescribes payment reference number requirements that trustees of superannuation entities and employers must conform with in relation to the electronic payment method that is used.
109. In the case of a BECS payment, the payment reference number is a unique 18 character identifier that may be alphanumeric and must be provided, generated or obtained by the sender and included by the sender (e.g. an employer or a superannuation fund) with each payment and data message to a destination entity (e.g., a superannuation fund).
110. This requirement ensures electronic payments (which flow via the banking system) and the related superannuation transaction details (which flow via the data messaging system) can be reconciled efficiently by the destination entity.
111. The payment reference number and the amount (in Australian dollars) must be added by the sender to the data message in accordance with the relevant schema set out in the Payment Methods document.
BECS Direct Entry
112. Payments may be made using either BECS direct credit or direct debit methods
113. If a payment is made using BECS direct credit, the sender of the payment is required to include the payment reference number and the amount of the payment (in Australian dollars) in the data message the payment relates to using the schema set out in section 2.3.1 of the Payment Methods document.
114. There are two alternative methods that can be used to generate an 18 digit payment reference number as set out in sections 2.3.1.1 and 2.3.1.2 of the Payment Methods document. The payment reference number produced under either method must allow the destination entity to reconcile the payment with the relevant data message.
115. If a receiving party offers BECS direct debit to employers, the employer should enter the payment reference number in the payment reference field of the data message as per section 6.4.4 of the Data and & Payment Standards - Contributions Message Implementation Guide document referred to in Schedule 4(a) to the Standard.
Employers using BPAY
116. It is the responsibility of the entities to establish BPAY capabilities with their preferred financial institution.
117. For an employer to use BPAY the employer must obtain the:
§ the Biller Code – a code to uniquely identify the entity (e.g. a superannuation entity) as a biller within the BPAY payment system; and
§ a customer reference number (CRN) – which identifies the employer entity making the payment. There must only be one CRN per payer (that is, employer). Generation of the CRN is the responsibility of the biller so that the biller can identify the payer and reconcile the payments.
118. When an employer makes a BPAY payment, the employer must include the Biller Code, Customer Reference Number and the amount of the payment (in Australian dollars) in accordance with the schema set out in the document.
Schedules 4(a) and 4(b) – Contributions and Rollover Message Implementation Guides
119. Separate message implementation guides (MIGs) have been developed in respect of the key transactions (business interactions) to which the Standard applies, namely contributions, and rollovers and transfers between superannuation entities.
120. The contribution and registration message specifications are set out in the document Data and Payment Standards - Contributions Message Implementation Guide (the Contributions MIG) as it exists from time to time.
121. The rollover message specifications are set out in the document Data and Payment Standards - Rollover Message Implementation Guide (the Rollover MIG) as it exists from time to time..
122. The Contributions and Rollover MIGs specify the data, data format and message format which must be used when sending an electronic message to a destination end‑point.
123. Each MIG incorporates business terms, which in turn have been specified in the SBR Definitional Taxonomy. The MIG specification allows the message output to be validated and assured by both sender and receiver as a standardised output with known content and meaning.
124. In-specie contributions and in-specie rollovers are not catered for within the Standard and existing processes will continue to apply to effect these transactions.
Contributions MIG
125. The Contributions MIG sets out the business interactions and message payloads required for certain contributions and for the registration of members (including updating existing member details).
126. Broadly, the Contributions MIG is relevant to employer contributions to APRA-regulated superannuation entities (including the registration process for contributions to a default fund and the updating of member details whether contributions are to default or choice funds), and SMSFs unless the employer contribution is made to a self-managed superannuation fund (SMSF) and the employer is a related party of the SMSF.
127. Contributions that are made by the ATO (other than in its capacity as an employer), by an individual, spouse or family member directly to a superannuation entity, or in specie are not subject to the Standard and therefore do not have to conform to the requirements of the Contributions MIG.
128. The Contributions MIG sets out the data elements that must be included in the electronic message that accompanies a contribution (the Contribution Transaction Request), the registration of a new member or an update to an existing member’s details (the Member Registration and Details Maintenance Request) and associated responses to those messages.
129. The Contributions Transaction Request message provides the transactional details associated with the contribution, such as the entity making the contribution, who the contribution is made on behalf of, the superannuation entity and product the contribution is made to, and the details associated with the payment transaction.
130. The Contributions MIG links with the Data and Payment Standards - Payment Methods document incorporated by reference in Schedule 3 to the Standard as contribution payments must use a payment method set out in that document.
131. The Contributions MIG links with the Data and Payment Standards - Message Orchestration and Profiles document incorporated by reference in Schedule 5 to the Standard to provide message transport linkage attributes (instructions and rules) for the Requests.
132. The Contributions MIG links with the Data and Payment Standards - Error Code Management document incorporated by reference in Schedule 6 to the Standard to provide the message specifications for electronic responses to Contribution Transaction Requests and Member Registration and Details Maintenance Requests that indicate to the message sender whether the request was received and processed successfully, or if not, what error codes will be returned in the response message.
Alternate arrangements
133. The Contributions MIG also provides for alternate arrangements for certain employer-fund relationships (contributions transaction relationships).
134. Employers can enter into an agreement, in writing, with a superannuation fund to use an alternate method to that specified in the Contributions MIG to capture and process contributions transactions messages if certain conditions and requirements are met. The conditions and requirements that must be met are set out in sections 8.2 and 8.3 respectively of the Contributions MIG. An employer and a superannuation entity that meet the conditions and requirements of the alternative arrangements meet the requirements of the Standard in relation to that contribution transaction relationship.
Rollover MIG
135. A superannuation rollover or transfer typically occurs if a member of a superannuation entity requests the transfer of the balance (in whole or part) of an account in one superannuation entity (transferring superannuation entity) to an account in another superannuation entity (receiving superannuation entity). In the MIG use of the term ‘rollover’ includes a transfer.
136. The Rollover MIG sets out the business interactions and message payloads required to initiate and undertake a rollover. The Rollover MIG is relevant to superannuation entities that may rollover or transfer a member’s benefits to another superannuation entity.
137. The Rollover MIG is not, however, relevant to closed products (see paragraph 13) as the Standard does not apply to such products, or to internal rollovers or in-specie rollovers.
138. The rollover business interaction is designed to be used in conjunction with ATO enabling services to assist in validating TFN, fund bank account details, the service delivery address and other details. How the enabling services are used within the rollover business interaction will depend on the specific rollover scenario and any relevant regulations. The Rollover MIG does not prescribe any particular use of these services.
139. Under existing law, it is not mandatory for the member to supply their TFN to a superannuation entity and therefore the TFN may or may not be available for use in the rollover transaction. If the TFN is quoted then the relevant superannuation entity must use the Super TFN Integrity Check (Super TIC) service provided by the ATO to validate the TFN and provide the TFN in the transaction. If this enabling service returns an invalid response, then the expectation is that the superannuation fund will work with the member to try to rectify the result.
Initiate Rollover Request message specification
140. If a superannuation entity (the receiving entity) receives a request from the member of another superannuation entity to rollover or transfer funds from that other superannuation entity (the transferring entity) to the receiving entity, the receiving entity is required to use an Initiate Rollover Request message to initiate that rollover or transfer with the transferring entity.
141. The transferring entity must be able to receive that message electronically regardless of whether the message is initiated electronically by another superannuation entity, a member (including through an intermediary acting on the member’s behalf) or the ATO.
142. To lodge the Initiate Rollover Request message an entity must be able to authenticate themselves to the entity that is to receive the message. The process used to enable the authentication (I am who I say I am) and authorisation (I can do what I am requesting) of the sender must be prearranged between both parties before electronic message exchange can commence.
143. While a member can initiate a rollover manually via a paper form, the Initiate Rollover Request message is mandatory for a superannuation entity (for example, if a member has approached the receiving entity which in turn seeks to initiate the rollover with the transferring entity).
144. Under Division 6.5 of the SISR 1994 a trustee of a transferring fund, for example, may be entitled to seek further information from the member. This action is not within the scope of the Standard and is managed by the transferring fund. Note that the transferring fund is still required to ensure the rollover or transfer occurs within the timeframes specified within the SISR 1994.
Partial Rollovers
145. In the case of partial rollovers the Standard does not include rules concerning preservation components or asset drawdown. The processes around these matters are dealt with under the default rules of the superannuation entity or under instructions from the member to the superannuation entity.
Rollover Transaction Request message specification
146. The Rollover Transaction Request message provides the transaction details of the rollover benefit which is sent by the transferring entity to the receiving entity. The data includes a payment reference number that is unique and which enables reconciliation with the matching payment by the receiving entity.
147. The rollover payment contains payment values and reference details of the benefits paid by the transferring entity to the receiving entity. The Rollover MIG links with the Data and Payment Standards – Payment Methods document incorporated by reference in Schedule 3 to the Standard as rollover and transfer payments by superannuation entities must use a payment method set out in that document.
Member notification
148. Notifications required to be provided to the member under the law by the transferring entity or the receiving entity are not covered in the Rollover MIG and instead rely on existing processes.
Schedule 5 - Message Orchestration and Profiles
149. The message orchestration and profiles that must be used are set out in the document Data and Payment Standards - Message Orchestration and Profiles (the Message Orchestration and Profiles document) as it exists from time to time.
150. To comply with the Standard entities must send and receive specified transactions in a form which meets the data and electronic messaging elements of the Standard.
151. The Message Orchestration and Profiles document defines the messaging services and interactions patterns.
152. Messaging services define how reliable and secure messaging can be transacted between parties over the internet using standards-based protocols. These services include packaging, transport, security and receipting of messages, as well as dealing with the special case of handling very large data payloads.
153. The Message Orchestration and Profiles document defines a flexible set of ‘profiles’ designed to fit differences in capability and roles in the superannuation user community.
154. Standardised agreements are used within the Message Orchestration and Profiles document to set out the collection of configuration parameters, specific to a profile, that apply to interactions between users.
Message packaging
155. The message packaging concepts in the Message Orchestration and Profiles document are based on the international standard OASIS ebXML Messaging Services Version 3.0: Part 1, Core Features, OASIS Standard, 1 October 2007 (‘ebMS 3.0 Messaging Standard’).
156. The conformance profiles outlined in the Message Orchestration and Profiles document are based on the AS4 Profile of ebMS 3.0 Version 1.0, Candidate OASIS Standard 013, 17 August 2012 (‘AS4 Profile’).
157. The specification of the PartyId type used is conformant with the OASIS ebCore Party Id Type Technical Specification Version 1.0,OASIS Committee Specification 01, 28 September 2010.
158. The Large Message Splitting and Joining function is as documented in the OASIS ebXML Messaging Services Version 3.0: Part 2, Advanced Features, OASIS Committee Specification 01, 19 May 2011 (ebMS 3.0 Advanced Features).
159. However, for the avoidance of doubt if there is a discrepancy between the specifications in any of the documents referred to in paragraphs 155 to 158, it is the specifications as set out in the Message Orchestration and Profiles document that must be complied with.
Profiles
160. Profiles establish the common basis by which two parties exchange messages.
161. For each bi-lateral exchange, each entity must select one of the profiles set out in section 3 of the Message Orchestration and Profiles document, which is reflective of their capabilities and also compatible with the profile adopted by the other entity. For example, an employer and a superannuation fund that deal with each other would each have to select compatible profiles.
162. The profile selected by an entity must also meet the following conditions:
§ the profile selected must not be an entry level profile (as set out in section 3.3) if the entity is a superannuation entity; and
§ the large-volume profile (as set out in section 3.4.2) must be used by an employer if the uncompressed size of business payloads within a message the employer generates exceeds the value of the PMode[1].BusinessInfo.PayloadProfile.maxSize parameter of Appendix 3 to the Message Orchestration and Profiles document.
163. Agreement to use specific profiles should be recorded by the parties when:
§ an employer registers with a fund for e-commerce purposes;
§ a fund becomes a participating member of a gateway;
§ two funds agree to select a common profile for direct exchanges; or
§ the two parties to an exchange agree to change their profile.
164. All profiles have been defined such that entities are at liberty to employ the services of an ebMS Intermediary (see ebMS 3.0 Messaging Standard Advanced Features, Section 2).
Entry level profiles
165. Subject to the requirements regarding the selection of profiles (see paragraph 3.1(b) of the document), an entity that is able to choose an entry level profile has a choice of two profiles:
§ the ultra-light profile (as set out in section 3.3.1); or
§ the light profile (as set out in section 3.3.2).
Advanced level profiles
166. Subject to the requirements regarding the selection of profiles (see paragraph 3.1(b) of the document), an entity may choose either:
§ the high-end profile (as set out in section 3.4.1); or
§ the large-volume profile (as set out in section 3.4.2).
Default agreements
167. Once each entity involved in a transaction has selected a profile (as set out in section 3 of the document), that is reflective of its capabilities and is compatible with the profile adopted by the other entity, the default agreement as relevant to the profile selected by each entity will apply. This is unless the entities to the transaction mutually agree to change the terms of one or both of the default agreement(s) that would otherwise apply.
168. If parameters are not provided in default agreements, it is because they are not relevant to the associated profile. See section D.3 of the ebMS 3.0 Messaging Standard for further details.
Processing modes
169. The processing modes in an agreement establish the configuration parameters on which a sender and receiver must agree when exchanging messages.
170. The processing modes may be varied by mutual agreement however the agreement must continue to meet the requirements of the relevant profile.
Summary of User Roles and Conformance Mapping
| User role | Best fit | Mapping to conformance profile |
| 1 | Employer – entry-level | Suits small to medium employer with low IT or message handling capability | ‘Ultra-light’ or ‘Light’ |
| 2 | Employer – advanced level | Suits employers with significant IT skills and message handling capability | ‘High-end’ or ‘Large-volume’ |
| 3 | Employer with Intermediary | Suits employers of any size who have opted to meet obligations by engaging a service partner or intermediary to act on their behalf | ‘Ultra-light’, ‘Light’, ‘High-end’ or ‘Large-volume’ |
| 4 | APRA fund | Applies to any APRA fund who choose to process prescribed transactions using their own IT resources. | ‘High-end’ or ‘Large-volume’ |
| 5 | APRA fund with Intermediary | Applies to any APRA fund who contracts with an administrator or other service partner | ‘High-end’ or ‘Large-volume’ |
| 6 | SMSF | Applies to any SMSF who choose to process prescribed transactions using their own IT resources. | ‘High-end’ |
| 7 | SMSF with intermediary | Applies to any SMSF who contracts with an administrator or other service partner | ‘High-end’ |
User roles
171. The Standard requires superannuation entities and employers to send and receive specified transactions in a prescribed form which meets the data and electronic elements of the Standard.
172. Entities can choose a conformance profile based on their IT capabilities (see paragraphs 160 to 166). The user roles set out below allow employers and trustees of superannuation entities to determine the most suitable profile for the entity.
173. This may include engaging an intermediary to assist a particular entity to meet applicable requirements under the Standard. For example, small employers will be able to use the Small Business Superannuation Clearing House to assist them in meeting their obligations under the Standard.
174. Existing dedicated employer contribution lodgement portals will also continue to be acceptable under the Standard if, and only if, they meet the requirements outlined in section 8 of the document Data and Payment Standards - Contributions Message Implementation Guide incorporated in Schedule 4(a) to the Standard.
175. Each user role can be mapped to a conformance profile. The combination of a user role and conformance profile helps define the implementation pathway a user can follow. It is important to note that complying with the Standard remains the responsibility of trustees of superannuation entities and employers, regardless of the profile they adopt or whether they engage intermediaries to assist them in meeting their obligations under the Standard.
Employer – entry level user role
176. The Employer – entry level user role is designed to be used by small to medium-sized employers that choose to send contributions messages using their own IT resources, but that may have a low IT or message handling capability.
177. An employer in this role would typically send new member registrations and contributions messages using a payroll software system or a custom-built application for processing contributions and generating messages. Messages may be pushed from the employer’s IT system over the internet to destination funds via an application gateway. The employer may not be able to handle automated error messaging from the fund.
178. To function in this role, an employer will need to have undertaken the following pre‑requisite steps:
§ be registered for e-commerce purposes with a complying fund;
§ obtained security credentials including user name/password; and
§ obtained a service address and other identifying details for the fund.
179. The Employer – entry level user role maps to the ‘Ultra-light’ and ‘Light’ conformance profiles set out in the Message Orchestration and Profiles document incorporated in Schedule 5 to the Standard.
180. Alternatively, an employer may engage an intermediary to assist them to meet their obligations under the Standard by adopting the Employer with intermediary user role which is described below.
Employer – advanced level user role
181. The Employer – advanced level user role is designed to be used by larger employers and/or those with significant IT and message handling capability, that choose to send contributions messages using their own IT resources.
182. An employer in this role would typically have a fixed IP address and an ‘always on’ message receiving capability. The employer would send new member registrations and contributions messages using a payroll software system or a custom-built application for processing contributions and generating messages. Messages may be pushed from the employer’s IT system over the internet to destination funds via an application gateway.
183. Error messages would be pushed by the destination fund back to the employer; alternatively pull scenarios could be supported.
184. While any employer in this role will be expected to be able to compress messages, employers with very large payrolls must also have the additional capability to split/join messages in accordance with the relevant conformance profile specification.
185. To function in this role, an employer will need to have undertaken the following pre‑requisite steps:
§ be registered for e-commerce purposes with a complying fund;
§ obtained security credentials including user name/password (and any additional credentials that may be agreed between fund and employer from time to time); and
§ obtained a service address and other identifying details for the fund.
186. The Employer – advanced level user role maps to the High-end and Large‑volume conformance profiles set out in the Message Orchestration and Profiles document incorporated in Schedule 5 to the Standard.
Employer with intermediary user role
187. The Employer with intermediary user role applies to any employer who contracts with a service partner or intermediary to meet all or part of the employer’s obligations under the Standard. An employer who contracts with a service partner or intermediary in this way remains subject to the Standard. If the service partner or intermediary does not conduct transactions on behalf of the employer in a way that conforms to the requirements of the Standard, the employer may be liable for a penalty.
188. To function in this role, an employer or their intermediary will need to have undertaken the following pre-requisite steps:
§ be registered for e-commerce purposes with a complying fund;
§ obtained security credentials including user name/password (and any additional credentials that may be agreed between fund and employer from time to time); and
§ obtained a service address and other identifying details for the fund.
The Employer with intermediary user role can map to any of the Ultra-light, Light, High-end or Large-volume conformance profiles set out in the Message Orchestration and Profiles document incorporated in Schedule 5 to the Standard.
189. The Employer with intermediary user role would apply to small employers that use the Small Business Superannuation Clearing House to assist them to meet their obligations under the Standard.
APRA fund user role
190. The APRA fund user role can apply to any APRA-regulated superannuation entity which chooses to process prescribed transactions using their own IT resources.
191. The APRA fund user role can map to the High-end or Large-volume conformance profiles set out in the Message Orchestration and Profiles document incorporated in Schedule 5 to the Standard. This mapping will depend on the capability of the entity and is a matter of choice for that entity, not a mandate.
APRA fund with intermediary user role
192. The APRA fund with intermediary user role can apply to any APRA‑regulated superannuation entity that contracts with an administrator or other service partner to meet all or part of the fund’s obligations under the Standard. An entity that contracts with an administrator or service partner in this way remains subject to the Standard. If the administrator or service partner does not conduct transactions on behalf of the entity in a way that conforms to the requirements of the Standard, the trustee of the entity may be liable for a penalty.
193. The APRA fund with intermediary user role can map to the ‘High-end’ or ‘Large-volume’ conformance profiles set out in the Message Orchestration and Profiles document incorporated in Schedule 5 to the Standard. This mapping will depend on the capability of the intermediary and is a matter of choice for an entity and its intermediary, not a mandate.
SMSF user role
194. The SMSF user role can apply to any SMSF which chooses to process prescribed transactions using their own IT resources.
195. The SMSF user role can map to the ‘High-end’ conformance profiles set out in Schedule 5 to the Standard. This mapping will depend on the capability of the fund and is a matter of choice for that fund, not a mandate.
SMSF with intermediary user role
196. The SMSF with intermediary user role can apply to any SMSF who contracts with an administrator or other service partner to meet all or part of the fund’s obligations under the Standard. An SMSF who contracts with an administrator or other service partner in this way remains subject to the Standard. If the administrator or service partner does not conduct transactions on behalf of the SMSF in a way that conforms to the requirements of the Standard, the SMSF may be liable for a penalty.
197. The SMSF with intermediary user role can map to the High-end conformance profiles set out the Message Orchestration and Profiles document incorporated in Schedule 5 to the Standard. This mapping will depend on the capability of the intermediary and is a matter of choice for a fund and its intermediary, not a mandate.
Application gateway role
198. The application gateway role applies to entities providing a gateway service on behalf of participating superannuation entities.
199. A gateway is responsible for:
§ receiving and routing contribution messages from employers to fund destination points;
§ receiving and routing rollover messages from fund to fund or government destination points;
§ receiving and routing error messages from destination funds to employers.
200. A gateway also performs other significant roles including message receipting and message tracking and reconciliation.
201. The application gateway user role maps to the application gateway conformance profile set out the Message Orchestration and Profiles document incorporated in Schedule 5 to the Standard.
202. The application gateway profile is included in the Message Orchestration and Profiles document in Schedule 5 to the Standard on the basis that a fund or an employer may need to choose a profile that is compatible with that gateway profile. However the gateway entity itself (not being a superannuation entity or an employer) is not subject to the Standard.
Schedule 6 - Error Code Management
203. It can be expected that in the normal course of transacting within the parameters of the Standard errors will occur from time to time. When such errors do occur, the error code management to be used is that which is set out in the document Data and Payment Standards - Error Code Management (the Error Code Management document) as it exists from time to time.
204. The Error Code Management document specifies the range of error codes from which a response must be selected in a business interaction sequence. Each code also contains a recommended plain text explanation which should accompany the error message.
205. Two Error Code Lists are specified for use under the Standard: the Generic SBR Error Codes (see section 4 of the document) and the Standard Specific Error Codes List (see section 5 of the document).
SBR Generic Error Codes
206. The Standard reuses certain error codes defined for use in the SBR Project. These error codes are shared for use with message standards for specific reporting obligations to government (defined in SBR). This shared use is identified through the naming convention for this category of error code (for example, these codes use the prefix SBR.GEN.GEN).
207. Other than as provided for in section 5 (Standard specific error codes) and section 6 (organisation specific error codes), the error codes used must be sourced from the generic SBR error codes that are available on the SBR website at http://www.sbr.gov.au.
208. The following generic SBR error codes are directly referenced by the documents Data and Payment Standards - Contributions Message Implementation Guide and Data and Payment Standards - Rollover Message Implementation Guide referred to in Schedules 4(a) and 4(b) to the Standard, respectively.
| Error | Severity | Short description |
| 1 | SBR.GEN.GEN.1 | Error | ABN {abn} is not valid |
| 2 | SBR.GEN.GEN.14 | Error | Invalid Entity Identifier Scheme {entityIdScheme} |
SuperStream Specific Error Codes
209. A list of errors codes specific to the Standard have been identified and are listed in the table at section 5 of the document.
210. This category of error message has been designed specifically for use in the rollover and contributions message standards. The naming convention for these messages will commence with SUPER.GEN. The balance of the error code name is determined by the use of that error code in the Standard.
211. For the errors identified in the table the associated error code as listed must be used.
Organisation Specific Error Codes
212. The error codes listed in the Error Code Management document are not intended to cover the total range of error conditions that may be experienced for transactions made in accordance with the Standard. Thus organisations may elect to implement specific codes that cover other errors. This category of error messages is catered for as organisation specific error messaging.
213. Section 6 of the Error Code Management document describes the required format for organisation specific error codes. The use of organisation specific error codes must be in strict accordance with the format set out in section 6.
214. Harmonisation of organisation specific error codes will be recommended by the SuperStream Advisory Council from time to time where that is considered appropriate.
215. An organisation that creates a specific extension to the error code list should publish the list of additional error codes on their website in an easily accessible, human-readable format.
Error severity
216. The following error severity levels will apply for the purposes of the Standard.
Error
217. This severity level indicates that the entire message could not be processed. This severity level may be applied to a specific element in the message and may be applied to indicate the maximum severity level of the MessageEvent.
Partial
218. This severity level indicates that part of the message could not be processed, but that other parts were successfully processed. This severity level must not be applied to a specific element in the message but may be applied to indicate the maximum severity level of the MessageEvent.
Warning
219. This severity level indicates that the message was successfully processed, but that one or more elements in the message may cause other problems in the system, and should be reviewed. This severity level may be applied to a specific element in the message and may be applied to indicate the maximum severity level of the MessageEvent.
Information
220. This severity level indicates that the message has been successfully processed, and may provide additional information back to the sender. In some cases an Information message will be used to indicate that the message was received and processed, however the intended business outcome (for example, actioning a rollover) did not occur for reasons beyond the scope of the actual message. This error severity level should not be applied to a specific element in the message but may be applied to indicate the maximum severity level of the MessageEvent.