The migration's real work sits inside the taxonomy

APRA published explanatory notes for its APRA Connect taxonomy artefacts on 16 September 2026. It is easy to file that material as technical documentation. Read operationally, it gives the people responsible for APRA collections a way to examine how data is defined, structured and tested against reporting rules.

For a financial-planning practice, the relevance is conditional. APRA's pages describe APRA collections and the entities that submit them. They do not say that every AFS licensee or advice practice is affected. The material matters where a practice forms part of an entity with APRA collection obligations, or where its operations support that reporting work.

The small fields carry the large consequences

The word taxonomy can sound abstract. In APRA's material, it is more concrete. The reporting taxonomies contain the elements and their properties relevant to a selected collection. They also set out the data types that may be used and the allowed values associated with a collection.

That creates a practical test. An internal field may appear to correspond with an APRA reporting element, yet use a different data type. A category may look correct, yet not match an allowed value. A completed form may still encounter a rule in the validation material.

Those are operational inferences from the components APRA identifies. The explanatory notes for the APRA Connect taxonomy artefacts list worksheets for the schema, elements, data types, enumerations, form sets, folders, forms and rules. For an entity submitting an APRA collection, the artefacts can therefore be read as a map of the definitions and structures its reporting process needs to handle.

The D2A change makes this an implementation issue

The context is APRA's migration of remaining D2A collections to APRA Connect. APRA says the migration is intended to deliver a single, modern data submission portal and remove the need to maintain the aging D2A client on industry infrastructure. APRA also says the timeline has been brought forward because of early decommissioning of D2A client vulnerabilities. APRA's migration page sets out that context.

The reasonable prediction is that moving collections to a different portal must also change what entities report. APRA's stated position is more qualified. It says it is not changing the collections as part of the migration, and that there are no plans to change the data scope, format, grain or frequency in the data collection forms.

That distinction matters. It points reporting teams towards the mechanics of expressing and validating existing information, rather than assuming the migration itself introduces a new reporting scope. The practical question is whether the current process can produce the existing information in the structure and form required by APRA Connect.

Read the taxonomy as a control document

A useful test is to stop treating the artefacts as something to consult only when a submission problem appears. Instead, use them to examine the reporting chain from internal data to submission.

Start with the schema and elements. Identify which internal fields feed each reporting element, and record where the source is manual, transformed or dependent on another system. Then examine data types and enumerations. The objective is not merely to confirm that a field contains something, but that it contains an acceptable value in the required form.

The form set and folders add another layer. APRA says the form set contains detailed information about the return name and label used in APRA Connect to identify the return. Where relevant, folders contain details for a return that can include multiple instances of the same form, such as state based forms. Those details should be reflected in the operating procedure, rather than left as portal knowledge held by one person.

Finally, examine the rules. APRA's artefacts include rules relating to the selected collection, while a validation rules spreadsheet provides a full list of rules across all collections. A pre-submission review against those rules gives the reporting team a way to identify mapping and data issues before a return is submitted.

Questions for reporting teams

The practical review can be organised around a short set of questions.

Which internal data fields map to each reporting element, and who owns those mappings? Are allowed values translated at the source, in an integration layer or during report preparation? Where a data type differs between an internal system and APRA Connect, where is that conversion controlled and tested?

How are repeated forms handled? If a return contains multiple instances of a form, can the process identify and retain the distinctions represented by those instances? Are state based or other folder structures understood by the people who prepare and approve submissions?

What happens when a validation rule identifies a problem? The answer should identify an owner, a correction path and a record of the change. A submission issue should not become an unexplained manual exercise that depends on institutional memory.

Teams should also separate stable reporting requirements from migration tasks. APRA says it is not changing the collections as part of the migration, and that there are no plans to change the data scope, format, grain or frequency in the data collection forms. That should help focus effort on the taxonomy, the submission process and the controls around them, rather than prompting an unnecessary redesign of the underlying reporting information.