APRA Connect support material

Yes. The APRA Connect test and production environments are distinct and separate environments and there is no data transfer between the two environments. All users will need to be set up in the production environment. Key steps: 

1. Nominate initial Regulatory Reporting Administrator (RRA) and request additional roles if required via D2A form (RRA_PROD: APRA Connect nomination for 13 September go live)
2. Login to APRA Connect and authenticate through myGovID/RAM to create your account
3. Await role assignment by an APRA Administrator
4. Once RRA role is assigned, the RRA can then assign roles to other users as they log in to APRA Connect

No. If your users have already been authorised in RAM as part of the process of onboarding in the test environment, or using other APRA services, you will not need to make any changes. Any new users will need to be authorised in RAM to act on behalf of an entity.

Please note that authorisation in RAM for APRA Services covers all APRA systems including APRA Connect test and production environments and Extranet.

The Regulatory Reporting Administrator (RRA) is responsible for:

• granting access to other RRAs, Preparers, and Service Providers
• managing user roles and permissions to ensure users remain current. This involves updating users' permissions when a user departs the organisation.

APRA requires one RRA to be nominated for each reporting entity (ABN). An RRA cannot assign additional roles to themselves, therefore in the event that the RRA is the only APRA Connect user for an entity, APRA will facilitate all required roles for the RRA in the production environment. 

RRAs are able to complete, validate and submit returns.

See more information on user roles and permissions in the APRA Connect Guide.

You can nominate the initial RRA through the D2A forms for either APRA Connect test environment (RRA: APRA Connect test nomination) or APRA Connect production environment (RRA_PROD: APRA Connect nomination for 13 September go live). For APRA Connect you will also need to nominate any additional roles for the RRA.

If you don’t use D2A contact us at dataanalytics@apra.gov.au. 

Nominating an initial Regulatory Return Administrator informs APRA who should be assigned the initial role in APRA Connect, however it does not create an account in APRA Connect. Account creation occurs through the first transaction of authenticating through myGovID. An APRA Administrator will then assign the RRA role to the user if the new account is created for a nominated RRA. 

Users must log in independently for each entity to view details for that entity. This means having a separate relationship established in RAM for each entity, and logging in and authenticating for each entity. You will need to log out and log back in selecting the next entity/ABN in RAM to view details for another entity.

When you login for the first time, you will not have any roles assigned to you and therefore will not be able to access functionality. 

If you are the first user onboarded for your entity, an APRA Administrator will assign your roles if you are a nominated RRA. If you are not a nominated RRA, you will need to wait until your entity’s nominated RRA logs into APRA Connect and has their roles assigned, so that they can proceed to assign you with your appropriate roles. 

Assigning a role is a manual step and there will be a lag between the time your user account is created and the time your role(s) are assigned. You will receive a notification once your roles have been assigned. 

When a user is authorised to access APRA services on its behalf in the Relationship Authorisation Manager (RAM), the email address used is the email that the APRA Connect user account will be created with. The email address that is used in RAM can be different from the email address used for your myGovID digital identity. When setting up authorisations in RAM for an entity, APRA requests the use of a business email address as this is the email address that will be used for APRA Connect notifications.  

APRA recommends against the use of shared email addresses because it removes the ability to identify individual users who have interacted with APRA Connect. We understand there are some instances where a shared email address is preferred however there are limitations for use. Users need to be aware that email addresses must be unique to a user, therefore if a second user attempts to login to APRA Connect using a shared email address already assigned to a previous user’s account, they will be unable to access APRA Connect.

Yes, see more information on RegTech access to APRA Connect test and how to request access. 

Auditors who need access to submissions of the entity they audit will need to contact the insurer and request for access to be granted to them. The Nominated Regulatory Reporting Administrator (RRA) for the insurer will be able to provide the auditors relevant access as per the entities internal policy. 

To be able to access APRA Connect, individuals need a myGovID.  Please refer to ATO’s published material to find out more about the Digital Identity system, myGovID and RAM.

You will need to log in at fund level with the relevant ABN to see allocated returns

The Superannuation Data Transformation returns are all submitted at the fund level, by logging in with the fund’s ABN. This is different to D2A and the SRF_001 form which allowed details for each fund to be submitted collectively by the trustee or administrator.

Yes, SRS 605.0 RSE Structure (SRS 605.0) return should be submitted before attempting to upload and submit all returns except data under SRS 332.0 Expenses (SRS 332.0). RSE Structure defines:

• Superannuation products
• Investment menus
• Investment options
• Fees and costs arrangements

This sets up each of the entity’s business operations in APRA's system so that they can lodge a range of regulatory returns.

SRS 605.0 needs to be submitted and up-to-date before submitting the returns under:

• SRS 251.0 Insurance Arrangements (SRS 251.0)
• SRS 550.0 Asset Allocation (SRS 550.0)
• SRS 606.0 RSE Profile (SRS 606.0)
• SRS 611.0 Member Accounts (SRS 611.0)
• Attestation 

SRS 605.0 and SRS 606.0 both need to be submitted and up-to-date before submitting the returns under:

• SRS 705.0 Performance Components (SRS 705.0)
• SRS 705.1 Performance Benchmark (SRS 705.1)
• SRS 706.0 Fees and Costs (SRS 706.0)

The Responsible Persons return is part of the Company Profile in APRA Connect and will not be allocated; instead users with the Corporate Profile User role will be able create a return when your entity profile needs to be updated. For more information on the Company Details and Corporate Profile refer to Chapter 5 of the APRA Connect Guide and for more information on permissions refer to 3.2.3 User roles.

The RSE Structure return updates the following sections of the Company Profile:

• Superannuation products
• Investment menus
• Investment options
• Fees and costs arrangements

The first time this return is submitted all the records will need the status of New; likewise when any new superannuation products/investment menus/investment options/fees and costs arrangements the status of New must be reported.

After the initial submission an entity will need to create an ad hoc submission when an RSE licensee wishes to make changes to an RSE’s products, investment menus, investment options or fees and costs arrangements. Entities will create their own RSE Structure return via the Create Return function.

The current ADI collections allow either XML or XLSX files to be uploaded and submitted via APRA Connect.

Note: this does not include CSV files. 

According to the relevant reporting standards, only certain combinations of the valid values are allowed.

APRA Connect enforces these combinations and the list of allowed combinations is embedded on the Schema worksheet of the corresponding reporting taxonomy.

APRA Connect uses a data model to ensure the integrity of data uploaded and manually entered. The Elements and Data Types worksheets of the reporting taxonomy will describe the specific properties that APRA Connect will enforce.

The data model enforces a range of properties, including (but not limited to):

• Length of data (including text and numerical fields);
• Allowed characters;
• Primary keys; and
• Mandatory fields.

If you try to upload a file that conflicts with the data model, the upload will fail and the data will not be loaded.

The reason the upload failed will be visible by clicking the Upload History icon on the View Return screen.

When manually entering data, APRA Connect will check for conflicts with the data model when the Validate & Save button is clicked.

When manually entering data APRA Connect will check for conflicts with the data model either as the data is entered or when the Validate & Save button is clicked.

Data for the September 2023 quarter must be submitted in accordance with the requirements of the relevant reporting standards GRS 001 and LRS 001. Where AASB 17 data is required to be submitted on a year-to-date basis, general and life insurers must report that data from the start of that entity’s financial year until the end of the relevant reporting period.

For example: 

• Insurers with a December year end: the data would cover the period from 1 January 2023 to 30 September 2023 on an AASB 17 basis for the September 2023 return.
• Insurers with a March year end: the data would cover the period from 1 April 2023 to 30 September 2023 on an AASB 17 basis for the September 2023 return.

The list below shows the reporting basis for each reporting standard:

Yes, private health insurers should submit flow data items on a discrete period basis after 1 July 2023. 

Given that the flow data items (e.g., Statement of Profit or Loss and Other Comprehensive Income items) are to be reported on a discrete period basis, HRS 310.0 Item 5. Amounts recoverable from reinsurers (e.g., Statement of Profit or Loss and Other Comprehensive Income items) (Total) will only reconcile with the corresponding item reported in the HRS 320.0 Part B RF1 Item 8. Amount recoverable from reinsurers on an annual basis. 

All Liability Roll Forwards are required to be reported on a 6 Month and Annual basis. This means that information will be submitted twice for each year, on an ongoing basis.

Please refer to the Reporting Standards GRS 320.0, GRS 320.0_G, HRS 320.0 and LRS 320.0 in the section Reporting periods and due dates for further details of the reporting obligations applicable to your institution. 

Some reporting forms contain closed tables (e.g., Private Health, or Life Insurance Financial Statements). In this instance, entities are able to submit multiple copies of the same table. These are known as Repeatable Forms (see section 6.6 of the APRA Connect Guide for further information).  LRS 300.0, Table 1 is a repeatable form.

To upload multiple copies of Table 1, each worksheet will require a sequential number in brackets at the end of the worksheet name, i.e. "(1)", "(2)", "(3)" etc so APRA Connect can differentiate between the different worksheets.

 This topic was covered in some detail in the webinar held on 30 March 2023. A recording of the webinar and a copy of the presentation are available under Videos for APRA Connect page on APRA’s website.

With APRA Connect, each return will be managed as one submission, which auditors will have to provide assurance against individually.

The forms for all AASB17 and capital collections respective to each industry are available in APRA Connect. All other forms will remain in D2A and will be allocated to the appropriate entities for data submission. 

See below for a full list of the forms to be submitted in APRA Connect and D2A respectively:

APRA expects at least limited assurance as required by professional standards and guidance notes issued by the Auditing and Assurance Standards Board.  This is because the information presented under GRS 311.0 Statement of Profit or Loss and Other Comprehensive Income by Product Group can be prepared by applying allocation principles under GRS 001 - Reporting Requirements (Attachment A – section 7). 

Insurers are required to complete all items in reporting form GRF 310.3 except for item 4 (underwriting expenses and acquisition costs), because item 4 has data items which would require application of the old accounting standard (AASB 1023). 

Yes. A private health insurer is required to submit data for each health benefits fund and the general fund under Reporting Standards HRS 110.0 Prescribed Capital Amount and HRS 118.0 Operational Risk Charge.  

Prudential Standard HPS 001 Definitions defines the general fund as “General fund consists of the operations of a private health insurer that do not form part of a health benefits fund of the private health insurer. This includes assets, liabilities, revenue and expenses not attributed to a health benefits fund.”   

Please note that APRA did not have good visibility of the activities within the general fund under the D2A reporting.  Assets/business held in the general fund could impact the health benefit fund’s capital adequacy such as any risky investments. This is one of the reasons APRA now requires reporting of the general fund.

Yes, APRA expects general insurers will still need to report an asset risk default stress amount arising from “non-reinsurance recoveries receivable on outstanding claims liability”, where relevant.  This is because failure to receive such a recovery in full would have a detrimental impact on the general insurer’s capital base.  

General insurers are to report the default stress amount on “non-reinsurance recoveries receivable on outstanding claims liability” within the line “GPS 340 net outstanding claims liabilities”. This is because under the requirements of GPS 340 paragraph 9, net outstanding claims is defined to be net of non-reinsurance recoveries, and therefore a default in “non-reinsurance recoveries receivable on outstanding claims liability” will affect the capital base via a rise in the reported “GPS 340 net outstanding claims liabilities”.

Report assets and liabilities as positive amounts except for contra asset (or liability) balances.

This sign convention is applicable for reporting in LRS 300.0, GRS 300.0, GRS 300.0.G, GRS 302.0.G, and HRS 300.0.

Report Revenue (inc. Gains) as positive amounts and Expenses (inc. Losses) as negative amounts.

This sign convention is applicable for reporting in LRS 310.0, GRS 310.0, GRS 310.0.G, HRS 310.0, LRS 311.0, GRS 311.0 and GRS 311.0.G. 

For Tables 1 and 2, report liabilities as positive amounts and assets as negative amounts. For Tables 3 and 4, report assets as positive amounts and liabilities as negative amounts.

This sign convention is applicable for reporting in LRS 320.0, GRS 320.0, GRS 320.0.G, and HRS 320.0.

For items 8.1 to 8.14, report assets as positive amounts and liabilities as negative amounts.

The table below sets out APRA’s expectations regarding the level of assurance to be provided by auditors for the annual data submitted by the General Insurers.

Level 2 (or Insurance Group)

In accordance with GPS 310, Group Auditors are required to provide limited assurance on the annual data submitted by Level 2 insurers.

APRA intends to consult on including this table within the prudential framework in due course. 
 

Insurers must not report capital risk charge related items as negative numbers. Common data items which were incorrectly reported as negative numbers were as follows.

• Aggregation benefit; and 
• Asset Risk Charge - impact of diversification.

No. “Adjustments to prescribed capital amount as approved by APRA” is not meant to capture the difference between the calculated PCA amount and the minimum PCA amount. APRA Connect will automatically adjust the final PCA amount to the minimum amount if the calculated PCA amount is below the minimum. 

“Asset Risk Charge - aggregated risk charge component” is net of “Asset Risk Charge “Impact of diversification” – This field should not be interpreted as requiring an amount before allowing for the impact of diversification.

No. Unless specified within the reporting standard, insurers must submit data items in whole dollars in APRA Connect. 

Yes. These data items must be reported if they are non-zero. These data items are used in calculating capital related ratios within APRA Connect. 

No. If DTL exceeds DTA, the insurer must report zero. This adjustment cannot be negative.

Items (e.g. premiums and claims incurred) under table 14 of LRS 200.0 are to be reported as positive numbers. If an insurer decides to report an item as a negative number, there must be a reason (e.g. if the insurer declines a large amount of claims reported in earlier periods, it may result in a negative number for claims incurred for the current period).

Items (e.g. premiums and claims incurred) under table 1 and table 2 of GRS 600.0 are to be reported as positive numbers. If an insurer decides to report an item as a negative number, there must be a reason (e.g. if the insurer declines a large amount of claims reported in earlier periods, it may result in a negative number for claims incurred for the current period).

Possible exposure types are outlined in Appendix A of LRS 117.0. Common data items which were incorrectly reported were:  

• Reinsurance arrangements with overseas reinsurers were incorrectly categorised as reinsurance arrangements with registered life companies (and vice versa); and 
• Reinsurance arrangements with counterparties with current grade 1, 2 or 3 were incorrectly categorised as reinsurance arrangements with counterparties with grade 1, 2 or 3 at time of agreement (implying they are no longer grade 1, 2 or 3). 

Exposure adjustments to underlying assets where there is a reduction in exposure (e.g. due to the use of risk mitigants) should be reported as positive numbers.

Risk mitigants relating to reinsurance underlying assets should be reported in table 2 and only those relating to non-reinsurance underlying assets should be reported in table 3.

Data fields “Adjusted Reinsurance Asset”, “Stressed Value Of Reinsurance Asset Under Insurance-stress Method” and “Stressed Value Of Reinsurance Asset Under Combination-stress Method” should be reported after allowing for any netting arrangements but before other risk mitigants.

Both these fields need to be completed across all reinsurance arrangements which are not with a registered life company or appropriate retrocessionaire.

LRS 117.0 sets out the requirements regarding what information must be provided to APRA. Common data fields which were incorrectly left blank were.

• ACRC limit for individual asset exposure after cumulative exposure adjustment; 
• Asset identifier;
• Asset identifier to which risk mitigant asset relates (if applicable); and 
• Stressed value of reinsurance asset under insurance-stress method.

The reporting taxonomy artefacts contain a template for uploading data via Excel. Please don’t make changes to these templates, in particular the starting row and worksheet name. Data that appears on rows prior to the starting row will not be uploaded.    

You will need to resubmit your return using the correct template (and starting row) to ensure all your data has been submitted.

The reporting taxonomies for each collection include an Excel template of the form, there are some features in the template that will aid entities when preparing their data and will reduce the time it takes to validate your return.

• The starting row of data is set by the template, any data that appears before this row will be ignored when the data is loaded into APRA Connect
• Only the EntityDetails and form layout worksheets are required to be submitted in APRA Connect; the size of the file being uploaded will be significantly larger if other worksheets are included.
• Mandatory fields must not be left blank: the Elements worksheet and form layouts specify which fields are mandatory; it is recommended that you review your data for missing fields before uploading to APRA Connect.
• Primary Key combinations must be unique: the Elements worksheet and form layouts specify which fields are primary keys; it is recommended that you review your data for duplicate combinations before uploading to APRA Connect.
• When uploading data into APRA Connect, the Key rather than the Label must be used for enumerations.

APRA publishes a reporting taxonomy artefact for every collection, which includes a template for the Entity Details and each form layout. These worksheets should be the only worksheets included in your upload, to avoid unnecessary large upload files.

The worksheets described above should not be altered in any way; in particular the starting row of the data entry cells or the worksheet name of the form layouts.

The Label is the human readable tag that aligns with the reporting standard and which will be shown if you view or download into Excel the data in APRA Connect. The Key is the machine readable tag used for uploading data into APRA Connect.

When manually entering data the Label will be displayed.

When uploading, APRA Connect requires the Key for enumeration members (not the Label). The Key and Label are listed in the Enumerations worksheet (pictured below).

In some cases, the Key and the Label will be the same – but in many cases the Key will be different:

• typically it will not contain any space and each word will be capitalised (camel case);
• special characters cannot be used (for example; % and >=);
• may appear shorter than the label.

An enumeration is a list of valid values. Typically you will see an enumerated list in a drop-down in APRA Connect. 

It is important to note that entities should be following CPG 234 Information Security regarding segregation of test and production environments, therefore you should be desensitising sensitive production data when used for testing.

APRA will allocate new returns, as they become available, so that entities can familiarise themselves with new collections. The returns will have lengthy due dates to ensure that entities can request a resubmission.

It is important to note, APRA may replace returns if issues are discovered – therefore entities should not assume that their data will remain in the Test environment.

Most current data collections will remain on D2A. As APRA replaces existing collections, they will be introduced on APRA Connect in line with industry consultation. The first data collections on APRA Connect are Private Health Insurance HRS 605 and the Superannuation Data Transformation collections.

All entities are required to keep entity information current in APRA Connect. This includes entity profile details such as addresses, contact person details, and Responsible Persons and Accountable Persons (where applicable). Entities are able to submit documents to APRA via the Ad Hoc return. See the APRA Connect Guide on Ad Hoc Return for more information.

The Ad Hoc return allows users to attach and submit documents through to APRA. A user must have the Ad Hoc Return permission to create and submit this return. The types of documents to be submitted through this return include:

• Actuarial  
• Aggregate Risk Exposures
• Audit 
• Information Security
• Intra Group Transaction and Exposures
• Margining and Risk Mitigation for non-centrally cleared derivatives
• Outsourcing/Business Continuity Management 
• Risk Management 
• Risk Management & Business Plan

Note: The Ad Hoc Return should not be used to submit data that is intended for upload into a data collection return.

See the APRA Connect Guide on Ad Hoc Return for more information.

An optional approval step in the form of a validation rule (a warning) prior to submission of a completed data return is available for selected collections. Entities may elect to activate the rule for all data returns (where available) by notifying APRA at dataanalytics@apra.gov.au. Once activated for an entity, the rule will apply to all applicable data returns. 

This rule does not apply for corporate returns.

Generally, entities are able to make this choice based on their own organisation’s needs and technical capabilities; however if the data being uploaded exceeds the row limits allowed in Excel then entities must use XML.

When your return is in a Complete status it means that all required fields contain data and the return is ready for submission. Returns that are submitted will have a status of submitted and will be removed from the Draft Returns list.

It is not recommended to make manual changes to files that have been uploaded because this will remove the traceability of changes for both your organisation and APRA. We strongly encourage entities to resolve issues in their source systems or source files to avoid the issue occurring again or to enable sign-off and verification processes.

APRA does not recommend entities with large data sets to opt into the no auto submit validation rule. 

APRA will not enable this validation rule for collections where large volumes of data are expected.

APRA has recently enabled offline processing of returns to address the performance issues experienced when APRA Connect went live. The introduction of offline processing will allow entities to click the Validate and Submit button and APRA Connect will process the submission offline, allowing entities to work on and submit other returns. Entities will receive email confirmation that the return has submitted successfully or that validation rules have been triggered.

In the situation where only the no auto submit validation rule is being triggered, entities will need to repeat the Validate and Submit process once more and therefore extend the time taken to submit.

There are a few options for either filtering or sorting the returns that appear in the Manage Returns screen:

• Click the grey column heading to sort by the selected column
• The Name or Reference columns can be filtered by typing text and using the key icon to narrow the search results by options like “Doesn’t contain” or “Equals”
• The Status column can be filtered by selecting status from the drop down menu
• The End data and Due date can be filtered by selecting a date from the date widget and the key icon can also be used to assist. For example: select the data of 31/12/2019 and “Is less than or equal to” to returns with an end date of 31/12/2019 or earlier

The error messages that are displayed when clicking Validate and Submit are the rules that have been triggered after running the validation process. If only Warnings rules have been triggered you will be able to provide explanatory comment. These validation errors will not automatically update after you have uploaded revised data; click Validate and Submit to run the validation process again.

The errors messages that are displayed when clicking Errors and Warnings are the rules that have been triggered the last time the validation process ran. If you have the no auto submit validation rule turned on, this screen will also show an error stating that the auto-submission has failed – this can be ignored and will not appear if you click Validate and Submit.

Note: you can also view validations that have triggered by clicking the exclamation icon next to the return status on either the Manage Returns screen or in the header of the Return (pictured below).

APRA publishes an XSD file for every collection that can be used to validate XML files created using your own systems.

APRA has generated some sample XML files to assist entities in preparing their own files for uploading.

APRA publishes all the taxonomy artefacts (including XSDs) on the APRA Connect Taxonomy Artefacts page.

Alternatively, the XSD can be accessed via APRA Connect: click the Upload Data icon for the desired return and click ‘download the definitional file’.

There are a few different ways to view the data you have uploaded and/or submitted. Open the relevant return, then:

• click the Upload History icon to view the file you uploaded; or
• click the Excel* icon to download a copy of the data you have entered.

*This will be restricted by the Excel row limits.

Note: the downloaded file will show the valid values as per the reporting standard (i.e. the Labels) and therefore cannot be reused to upload and submit data.

In order for an XML file to be well formed dates must use standard XML conventions and must be expressed as YYYY-MM-DD. More information is available here: https://www.w3schools.com/xml/schema_dtypes_date.asp

The format of dates in XML files supersedes the date formats specified in the reporting taxonomies.

The Data Types worksheet in the reporting taxonomy will describe each data type that is used in the specific collection. Data types include: string, date, number, Boolean and enumeration.

The Number data type can have a range of properties, including (but not limited to):

• Percentage: typically, percentages are reported as unconverted numbers to xx decimal places (xx could be any number). Therefore, “Percent (2 decimal places)” would see 12.34% reported as 0.1234.
• Integer: will allow up to 19 digits before the decimal place and no digits after the decimal place.
• Monetary: will allow up to 19 digits before the decimal place and 9 digits after the decimal place.
• ABN Integer: 11 digits before the decimal place and no digits after the decimal place.
• Text (##): the number of characters allowed in a string will be controlled by either Min Length and/or Max Length properties.

On some occasions we may restrict certain characters from being entered, for example: Text (20) uses the following regular expression to ensure that only the following are uploaded: upper and lower case letters, numbers, a colon (:) or a dash (-).

^[a-zA-Z0-9:-]*$

More about regular expressions can be found at https://regex101.com/

The primary key ensures each row is unique. The Elements worksheet of the reporting taxonomy will describe the primary keys as either Yes or No.

Primary keys will always be mandatory to complete.

The Elements worksheet of the reporting taxonomy will describe the mandatory fields as either Yes or No.

When you view a collection in APRA Connect, mandatory fields will be marked with a red asterisk.

In some cases, APRA will define certain combinations of enumerations that are allowed in combination with another enumeration. To capture these combinations, each reporting taxonomy workbook will contain an embedded file in the Schema worksheet. This file is called the ‘hole restrictions file’.

For example, if a collection requires the Country and State to be reported only the corresponding Australian states would be accepted if Australia is listed as the county.

APRA Connect will use the “permitted combinations” validation rule to ensure the correct combination of enumeration keys has been applied. For uploads containing a large number of rows, it is highly recommended that you ensure the correct Key has been used before uploading to APRA Connect.

If this validation rule is triggered, an error will provide the erroneous combination of enumerations and the member specified. This error provides the necessary information to identify the data that needs to be amended.

An example is pictured below: