Service · Web development

Custom regulatory reporting platform development.

A custom platform that automatically generates compliance reports from your source systems and submits them to DNB, AFM, ECB or another supervisory authority. Built on a solid data foundation, with an audit trail for every figure and a review flow that enforces the four-eyes principle.

XBRL & SBRDNB DLR submissionData lineageFour-eyes review

Regulatory reporting is no longer spreadsheet work.

Supervisory pressure increases every year. Banks, insurers, pension funds, asset managers and increasingly also energy and large industrial companies must submit standardised reports at fixed intervals, often in XBRL, iXBRL or SBR format, frequently subject to in-depth validations, and always with the expectation that the figures are correct and traceable to their source.

Since 2015, we have been building custom software for sectors where that data foundation never fits neatly into an off-the-shelf package. No loose Excel macros, no manual copy-and-paste from the ERP, but one continuous line from source data to submitted report, with data lineage for every line, a review flow for each report and an audit trail that records every change.

The difference between a good and a poor reporting platform rarely lies in the export layer. Generating XBRL or SBR is a solved problem. What matters is everything that comes before it: how cleanly the source data is loaded, how transparent the calculations are, how quickly a variance can be traced back to the transaction, and how easily an internal audit can follow your figures. That is where the value lies, and that is where we invest most of the sprint budget.

Three types of regulatory reporting platform.

Depending on your sector, the number of reports and how deep the integrations with source systems need to go. We advise which format suits you during the first conversation.

Compact project · fixed sprint budget

Reporting add-on for your existing stack

A module that plugs into your existing data warehouse or ERP. It calculates the figures according to a specific reporting template (Solvency II QRT, a COREP return, a CSRD annex), generates the XBRL or SBR file, and provides a review workflow before you submit.

One reporting typeXBRL/SBR exportReview workflowAudit log
Mid-sized project · fixed sprint budget

Reporting platform with a data foundation

A central reporting warehouse that pulls data from multiple source systems (ERP, core banking, custodian, transaction system, accounting) and builds a set of reports on top of it. Includes variance analysis, dashboards for submission deadlines and compliance mapping, so that a single control feeds multiple reports.

ETL and warehouseMultiple reportsData lineageCompliance mapping
Larger project · fixed sprint budget

Enterprise reporting platform

A mission-critical platform with deep integrations into supervisory authority portals (DNB DLR, ECB SDW, EBA, AFM, NZa), four-eyes sign-off for each report, automated submission, and variance analysis against historical periods. Designed for organisations producing dozens of reports a year.

A sanctions match does not call for periodic reporting but for an immediate notification. See Sanctions compliance software.

DNB DLR submissionFour-eyes sign-offVariance analysisMulti-entity

What we typically build in a regulatory reporting platform.

The building blocks vary by sector, but this is the toolkit we draw from, combined into a platform that suits your reporting landscape.

Data foundation

ETL and reporting warehouse

Ingestion from ERP, core banking, CRM, accounting, transaction systems, custodians and brokers. A clean data model with version history, so that every period can be recalculated reproducibly.

Calculations

Reporting templates by type

Formulas and validations for each report: Solvency II QRT, COREP, FINREP, NICA, MiFID II transaction reporting, SFDR, EMIR, IFRS 9, BCBS 239, EBA stress testing, FATCA, CRS, CbCR, BEPS Pillar 2, SBR tax reporting.

Export

XBRL, iXBRL and SBR

Generators for the current taxonomy years. Validation against the official schemas before the file enters the submission flow, so that technical rejection by the portal is almost entirely ruled out.

Submission

Integrations with regulator portals

Where APIs are available: direct submission to DNB DLR, ECB SDW, AFM, EBA and NZa. Where that is not possible: a validated file ready in the portal, with a log record of who uploaded what and when.

Workflow

Data entry, review and sign-off workflow

Preparer, reviewer and approver with clearly defined permissions. Includes notifications, deadlines per report, and a dashboard that shows, per cycle, which reports are on track and which need attention.

Control

Variance analysis and data lineage

For every figure in the report, visibility into the source transaction, the calculation, the previous value, and the explanation given for any change. Essential for internal and external audit, and for your own quality assurance.

Sectors in which we build regulatory reporting.

Reporting pressure runs through almost every regulated sector. A selection of the types of organisations we work with, and the reporting landscape that goes with them.

Financial sector

Banks and payment institutions

COREP, FINREP, NICA, MiFID II transaction reporting, BCBS 239 data quality, IFRS 9 expected loss, EBA stress testing and ECB reporting. Often combined with a deep core banking system and multiple custodians.

Insurers

Solvency II and international reporting

Solvency II QRT, ORSA substantiation, FATCA, CRS and CbCR. With platforms that link the actuarial calculation and the reporting layer in a single lineage trajectory, so that the external auditor can easily trace the figures.

Pension funds

DNB returns and Wtp reporting

The returns to DNB plus the additional reports introduced by the Dutch Future Pensions Act (Wet toekomst pensioenen). With integrations to the pension administrator and the asset manager from which the investment data originates.

Investment management

SFDR, EMIR and MiFID II

SFDR sustainability templates, EMIR transaction reporting and MiFID II best execution. For asset managers and fund houses working with multiple brokers and custodians who need to consolidate their data before reporting.

Energy, industry and multinationals

ACM, EU Taxonomy, BEPS and CbCR

For energy companies: ACM/CBS reporting and EU Taxonomy. For multinationals: BEPS Pillar Two, CbCR and transfer pricing documentation. For manufacturing: REACH and RoHS where product data must meet compliance requirements.

Healthcare and public sector

NZa, IGJ and Woo

For healthcare providers: NZa claims reporting, IGJ reporting and EHR integrations. For government: Woo reporting and annual report requirements that need to be supported by a reporting layer rather than compiled by hand.

What you get at the end.

A production-ready reporting platform plus everything around it, so that you and your compliance and IT team can manage and extend it yourselves.

  • The reporting platform itselfProduction and staging environments in your cloud (GCP, AWS, Azure) or hosted by us, with encryption in transit and at rest.
  • Data foundation and lineage layerETL from your source systems, a central reporting warehouse, and a lineage overview that shows, for each figure in the report, where it originates.
  • Reporting templates by typeCalculations, validations and XBRL/iXBRL/SBR export for the reports relevant to your entity. Templates are version-resilient, so you can load new taxonomy years.
  • Codebase and documentationFull source code, build instructions, architecture diagrams and a functional description per report (which formula, which source fields).
  • Admin guide for compliance and ITHow to submit a report, how to investigate a variance, how roles are assigned, and how the audit log is read by internal and external auditors.
  • Management contract (optional)Ongoing maintenance: new taxonomy years, updated validations, integrations, monitoring and security patches. Fixed monthly fee, with four response-time levels.
Not yet sure about a large project?

Test your idea first: a working prototype in 1 day

With OneDayBuild, we turn your idea into something tangible in one day for €1,150, so you can see whether further development is worth the investment. Decide to go ahead with the full build? Then we credit the full cost.

Explore OneDayBuild →

When a custom platform is the right choice.

Four situations in which clients come to us. If you recognise one of them, we'd be happy to talk further.

Off-the-shelf package doesn't fit

OneSumX or Adenza is too heavy

Large enterprise packages such as Wolters Kluwer OneSumX, AxiomSL/Adenza or Moody's BankBeyond suit the very largest institutions, but for mid-sized banks, insurers and pension funds they quickly become a cumbersome solution for a specific set of reports.

No data foundation

Figures are compiled by hand

Many reporting projects begin not with the report but with the data. If your figures currently reach compliance every month via Excel files from controllers, a shared data foundation with lineage is the first step.

New obligation

CSRD, DORA or MiCA is coming

Reporting requirements change faster than most off-the-shelf packages can keep up with. For new obligations such as CSRD, DORA incident reporting or MiCA market data, custom development is often the quickest route to a working solution.

Depth of integration

Many source systems, one report

When a report combines data from core banking, custodians, brokers, transaction systems and ERP, standard connectors quickly reach their limits. A platform built around your architecture can handle the variance analyses and data quality checks on top of that integration properly.

How a reporting project works.

1

Introduction and scoping

A conversation with your compliance, finance and IT teams to map out which reports apply, which source systems you have, and where the pain currently lies. By the end we'll know whether an add-on is sufficient or whether the data foundation needs to come first.

2

Data model and report analysis

We map the reporting templates (COREP, FINREP, Solvency II QRT, SBR tax filings, ESG annexes) onto your source fields. For each figure we record the formula, the validations and any exceptions. That document later also serves as the audit justification.

3

Building in sprints

A working build every two weeks. Compliance officers, controllers and internal audit test along on real (anonymised) data. The first report is ready after a few sprints, after which the following reports are added in phases.

4

Parallel run, rollout and maintenance

We run at least one reporting cycle in parallel with your current process. Differences are investigated and documented. After that it goes live, with an agreed maintenance arrangement for new taxonomy years and further development.

Frequently asked questions.

What clients typically want to know before we start.

Will you replace Wolters Kluwer OneSumX, Adenza or another enterprise package?
For the largest banks and insurers already running entirely on OneSumX, Adenza/AxiomSL or Vermeg, no, that wouldn't make sense; those packages are built precisely for your scale. We more often build custom solutions where a standard package doesn't fit: for mid-sized organisations, for specific reports alongside the main package, or for sectors where standard software isn't available (such as parts of energy, healthcare or crypto).
How can I generate compliance reports automatically?
The core is a data foundation into which source figures are loaded with lineage, plus calculation templates for each report that run on that foundation. With every run, the XBRL or SBR file is generated, including validations. The reviewer sees which figures changed compared with the previous period (variance analysis), signs off in a four-eyes workflow, and then the file can be sent to the regulator. Fully automated, with human sign-off.
What do you mean by "data foundation for compliance and reporting"?
A good data foundation is the only sustainable solution for compliance reporting. In practice: a centralised reporting warehouse, with standardised ETL from your source systems, data-quality checks at the point of loading, and data lineage so that for every figure in a report you can see which underlying transaction it is based on. Without this foundation, every report becomes a manual reconciliation all over again.
Do you support SBR, XBRL and iXBRL?
Yes. SBR is the Dutch standard for tax submissions and annual accounts filings; XBRL and iXBRL are used for the European taxonomies (ESEF, EBA, EIOPA). We build report generators that know the correct taxonomy version, run validations and prepare the export file for the submission portal.
Can you submit automatically to DNB DLR, ECB SDW or AFM?
For DNB DLR (Digital Reporting Portal) and comparable portals, we build a direct submission integration wherever the regulator technically permits it. Not all portals offer an API for automated submission; in that case the platform prepares a validated file ready for manual upload by the authorised user, with a log of the upload confirmation.
What is the difference with DORA compliance, KYC or CSRD software?
Regulatory reporting specifically concerns the legally required reporting to regulators. Adjacent to it, we also build DORA compliance software for operational resilience, KYC/AML software for customer onboarding, and CSRD/ESG reporting software for sustainability reporting. The platforms can feed each other through a shared data foundation.
How do you handle the audit trail and the four-eyes principle?
Every change in a reporting cycle, whether a recalculation, a manual correction or a sign-off, is recorded with user, timestamp, and old and new value. The four-eyes workflow is built into the submission process as standard: a preparer drafts, a reviewer approves, and an approver signs off. External auditors receive read-only access to the audit log for their review.
How long does a project like this take?
For a single reporting type with reasonably clean source data, a working platform is achievable in a few sprints. For a multi-report reporting platform with a data foundation, expect a trajectory of several sprints, often rolled out in phases so the first reports are live while the next ones are being built.
What determines the cost of a reporting platform?
The main factors are: the number of reports, the complexity of the calculations behind each report, the number of source systems feeding data in, and how clean that source data is. Ask us for a no-obligation estimate based on your specific situation — that gives you far more direction than a general price range.

Talk to us about your regulatory reporting platform.

A thirty-minute introductory call, no strings attached. We listen to which reports you produce today, where it hurts and which new obligations are coming your way. We then give you direction you can actually use, even if that direction isn't "build custom software". If your question is internal, take a look at management reporting first, or at enterprise software development for a broader programme.

Edit content