Case Study
The Opportunity
Financial services organisations have many obligations to manage with their regulators. Being a Registrable Superannuation Entity requires regular reporting of business activities to APRA.
APRA is moving to a collaborative common understanding of data collection. APRA’s data strategy involves a shift to collecting source data to minimise the burden on entities. APRA’s intent is to design data collection to reflect the dataset entities required to conduct day-to-day business.
Aligning with APRA’s shift, a financial services institution recognised the need to develop a coherent approach to collecting and reporting their data. They called upon Robinson Ryan to achieve an uplift in data planning and design practices.
There was a hard deadline for delivering the data solution, which meant that planning and design were critical to produce the data that APRA wanted on the first build.
Our Approach
Robinson Ryan’s financial services and APRA reporting specialist lead joint business and technology workshops to map the APRA data requirements to the current state of the enterprise data model.
This was backed by Robinson Ryan’s data architecture, data modelling and design specialists providing direction, data models, and guidance on implementation. The project involved:
- Data architecture activities aligned with the enterprise architecture and the enterprise data model.
- Data modelling activities involving the creation of conceptual data models to document the scope of the reporting obligation for the business owner. Logical data models were created to document each piece of data required by APRA alongside existing data coverage.
- Collaboration with data developers over the logical data model, assessing implementation options and the best approach for designing the data store that would hold data while it is being collected from the source systems.
This approach led to our data modeller recording the APRA requirement and filling the gap between the enterprise data model and the reporting requirements.
The conceptual data model made it easy for the business to recognise their data and understand why the data model looked the way it did. The business knew which systems the data needed to come from and how the data would be integrated. They were confident in signing off the design of the data solution.
The logical data model made it easy to reconcile the scope of data expected by APRA and how it was going to be collected. The developers knew how they would build the database, integrate data from multiple systems, and create data for the reporting requirement.
The business sponsor and technology implementor agreed on the data solution.
Outcomes Achieved
- The business now has nine APRA reporting obligations documented in a manner the business understands.
- The technology teams are confident they understand what the business wants and how they can deliver it.
- The enterprise architecture team has additional data assets documenting their data architecture and aligns with their view of data.
- The logical data model is ready to be forward-engineered into physical database schema.
