• Optimisation of responses for contributions

    Purpose

    The purpose of this document is to provide additional guidance on the implementation of error and outcome responses for member registrations and contributions under the SuperStream Data Standard (the Standard).

    Background

    This guidance note describes a number of alternative approaches to error and outcome response messaging for the SuperStream data standard. These proposals have arisen following feedback from industry, in particular the SuperStream Standard Technical Committee (SSTC) and the ASP Lead Working Group. The intended purpose of these proposals is to provide the industry with options to optimise response messaging for contributions.

    This guidance note must be read in conjunction with the Superannuation Data and Payment Standard Schedule 4(a) document Data and Payment Standards – Contributions message implementation guide, and the Schedule 6 document Data and Payment Standards – Error Code Management.

    Optimisations

    This guidance note outlines two optimisations of the Standard with respect to error and outcome responses. Each of the optimised approaches is an optional alternative to, or extension of, the Standard.

    These are:

    1. Notification of success no longer required under progressive response pattern.

    2. New optional response code to allow warnings to be provided following successful processing.

    In each case the decision to exercise one of these optimised approaches is at the discretion of the fund (as it is the fund that needs to prepare responses to member registration request and contribution transaction request messages).

    Employers should consider how to address the potential to receive a response in accordance with the Standard as published or alternatively a response in accordance with this guidance note (which in either case may imply that no response is received at all).

    Notification of success no longer required under progressive response pattern

    Optimisation

    Funds are no longer required to explicitly communicate success for all members in a contributions transaction request under a progressive response pattern.

    Implications

    This optimisation dramatically reduces the number of response messages that would have been sent under a progressive severity level.

    Similarly to non-progressive response patterns, the employer and their service provider would work on the basis that a contribution is successful unless contact is made by the fund to indicate otherwise.

    Note: this does not apply for member registrations. A member registration outcome response is required in all cases, accordingly explicit closure is still required under a progressive response pattern for all members contained in the relevant member registration request message.

    Reference to published Standard

    The current requirement is that where a progressive response pattern is used separate events must be reported for all members that were included in the related contributions transaction request. This includes where a member’s contribution was successfully processed.

    Reference: Schedule 6 document Data and Payment Standards – Error Code Management, section 3.5.

    New response code to allow warnings to be provided following successful processing

    Optimisation

    A new response code has been specified that MAY be used to pass corrected data or warning messages from a fund to the employer, where either:

    a. incorrect data is included in a member registration or contribution transaction request (for example, an incorrect member ID) and corrected data is returned to the employer

    b. to identify fund specific elements related to the MRR/CTR that are optional under the Standard but required by the rules of a particular fund to determine member benefits.

    The code is specified as follows:

    • Error code: SUPER.GEN.CNTRBTN.9
    • Severity: Warning
    • Short description: 'Contribution has been processed with warnings. Please review long description for further details'.

    Long description examples could include:

    • Incorrect {elementname} was supplied
    • Correct {elementname} is {correctdata}
    • {elementname} is required by the fund for contributions made for this USI.

    Where:

    • {elementname} is the name of the element for which incorrect data was originally provided
    • {correctdata} is the corrected data to be communicated back to the employer.

    Implications

    This would be used where:

    1. incorrect data was found in the contribution or registration but the fund was still able to process the transaction (either by relying on other data, or exercising an out of band business process to resolve the issue)
    2. data that is optional under the Standard but required by the rules of the fund has not been provided in a member registration or contribution transaction request message. The fund should still process the transaction (either by relying on other data, or exercising an out of band business process to resolve the issue).

    Utilising the severity ‘Warning’ in the response is a call to action on the employer or their service provider to consider the corrected or requested data from the fund and what action they can and should be taking to address it.

    Reference to published Standard

    A new error code (SUPER.GEN.CNTRBTN.9) for this response code will be included in a future update of the Schedule 6 document Data and Payment Standards – Error Code Management.

    Reference: Schedule 6 document Data and Payment Standards – Error Code Management, section 5.

    Recommended guidance

    Funds should consider the alternative approaches in this guidance note and determine whether the optimised approach is suitable for their solution. If funds do choose to implement these optimised approaches they should consult with their key stakeholders, especially employers and their service providers, to help ensure interoperability.

    Employers and their service providers should consider the alternative approaches in this guidance note and determine how to address the potential to receive a response in accordance with the Standard as published or alternatively a response in accordance with this guidance note.

     

    Attachment 1 – Example scenarios

     Optimisation 1:

    Removing the requirement to explicitly communicate success for all members under a progressive response pattern.

     
     Optimisaton1

     

     

     
     Optimisation 2:

    Addition of new response codes to allow warnings to be provided following successful processing.

     

    Optimisaton2

      Last modified: 16 Dec 2015QC 42230