CDAP – Compliance Data Assurance Platform¶
Building the metadata-driven foundation for regulatory reporting, data quality, and compliance intelligence.
1. Introduction¶
The Compliance Data Assurance Platform (CDAP) is an initiative by Cygnet Pericon to modernize how financial institutions manage regulatory reporting, data quality, metadata governance, and compliance intelligence.
CDAP is the culmination of more than 25 years of experience in regulatory reporting projects across Indonesia and the Asia-Pacific region. It represents the evolution of lessons learned from legacy platforms, proprietary validation engines, regulatory reporting implementations, and large-scale banking data integration projects.
Our vision is simple:
Regulatory knowledge should be separated from execution technology.
Banks should not have to rebuild regulatory logic every time a reporting requirement changes. Instead, regulatory intelligence should be managed as metadata and deployed into whichever execution technology best fits the organization.
2. Why CDAP Exists¶
For decades, regulatory reporting solutions have been tightly coupled to specific technologies:
- Validation rules embedded in XML files
- Business logic hard-coded in SQL
- Data transformations buried inside ETL tools
- Regulatory knowledge trapped inside vendor applications
This creates several challenges:
- High maintenance costs
- Vendor lock-in
- Slow response to regulatory changes
- Difficult migration between platforms
- Limited transparency and auditability
CDAP was created to address these problems through a metadata-first approach.
Instead of storing regulatory knowledge inside code, CDAP stores knowledge as structured metadata that can generate multiple downstream artifacts.
3. Historical Background¶
3.1 The Regulatory Reporting Journey¶
Cygnet's regulatory reporting journey began around 2000 through projects involving:
- STB Systems
- Lombard Risk (who acquired STB Systems)
- Vermag (who acquired Lombard Risk)
- Anterprix
Over the years, Cygnet implemented regulatory reporting solutions for numerous Indonesian banks and financial institutions.
These projects revealed a recurring challenge:
The true intellectual property is not the software engine. The true intellectual property is the regulatory knowledge.
Execution engines come and go.
Regulations evolve continuously.
The valuable asset is the knowledge layer that understands:
- Regulatory forms
- Data requirements
- Validation rules
- Business definitions
- Cross-report consistency requirements
This realization became the foundation of CDAP.
3.2 From GoDQ to CDAP¶
One major influence on CDAP was Cygnet's experience with GoDQ.
GoDQ successfully demonstrated that validation rules could be externalized from application code.
However, the next logical step was larger:
Instead of merely storing validation rules externally, why not store all regulatory knowledge as metadata?
This led to the creation of CDAP.
4. Core Philosophy¶
CDAP is built around five principles.
4.1 Metadata First¶
Everything should be represented as metadata whenever possible.
Examples:
- Data elements
- Validation rules
- Business definitions
- Reference codes
- Aggregation logic
- Reporting forms
4.2 Execution Engine Independence¶
CDAP should not depend on a single execution technology.
The same metadata should be capable of generating:
- Great Expectations assets
- SQL validation scripts
- Python validation code
- GoDQ XML
- dbt tests
- Documentation
4.3 Regulatory Intelligence Separation¶
Execution engines perform processing.
CDAP owns knowledge.
This separation allows regulatory intelligence to survive technology changes.
4.4 Open Standards¶
Where possible, CDAP embraces open technologies.
Examples include:
- Great Expectations
- dbt
- PostgreSQL
- Python
- Open metadata formats
4.5 Reusability¶
A rule defined once should be reusable across:
- Banks
- Regulatory frameworks
- Validation engines
- Testing environments
5. What CDAP Is¶
CDAP is not a single application.
CDAP is a platform consisting of several connected domains.
Metadata Repository¶
Stores:
- Regulatory metadata
- Data dictionaries
- Form definitions
- Reference codes
Validation Repository¶
Stores:
- Validation rules
- Rule patterns
- Rule parameters
- Test cases
Rule Generation Framework¶
Produces:
- GX Expectations
- SQL scripts
- GoDQ XML
- Documentation
- APIs
Governance Layer¶
Manages:
- Versioning
- Approval workflow
- Change history
- Audit trails
6. Relationship with Other Cygnet Components¶
CRRR¶
CRRR focuses on:
- Regulatory knowledge
- Reporting requirements
- Form structures
- Regulatory history
CRRR answers:
What must be reported?
RRDF¶
Regulatory Reporting Data Foundation.
RRDF provides:
- Canonical business entities
- Banking data model
- Regulatory abstraction layer
RRDF answers:
How should data be organized?
CDAP¶
CDAP provides:
- Validation assets
- Data quality assets
- Testing assets
- Metadata management
CDAP answers:
How do we assure quality and compliance?
CRRS¶
CRRS is the execution solution.
CRRS answers:
How do we operationally produce the report?
7. Current Program Status¶
The project is currently moving from concept definition into implementation.
Key workstreams include:
| Area | Focus |
|---|---|
| CRRR | Regulatory knowledge model |
| RRDF | Canonical banking data model |
| CDAP | Validation metadata repository |
| Antasena Pilot | First end-to-end implementation |
| Asset Discovery | Existing metadata inventory |
| Rule Pattern Library | Reusable validation patterns |
Current ownership:
- HS – Program Leadership
- HZ – RRDF Business Entity Model
- YA – Validation Pattern Library
- PK – Metadata Extraction and Asset Inventory
- DS – Metadata Lifecycle and User Experience
8. The Antasena Pilot¶
Antasena has been selected as the first strategic pilot because it provides:
- Rich metadata
- Large rule volumes
- Real production use cases
- Clear business value
The pilot will validate:
- Metadata modeling
- Rule generation
- Validation automation
- Repository architecture
Success in Antasena establishes the foundation for expansion into other regulatory frameworks.
9. Target Architecture¶
+----------------+
| Regulatory Docs|
+--------+-------+
|
v
+----------------+
| CRRR |
| Regulatory |
| Knowledge Base |
+--------+-------+
|
v
+----------------+
| CDAP |
| Metadata + |
| Rule Repository|
+--------+-------+
|
+-------------------+-------------------+
| | |
v v v
+-----------+ +------------+ +-------------+
| GX Assets | | SQL Assets | | GoDQ Assets |
+-----------+ +------------+ +-------------+
|
v
+----------------+
| CRRS |
| Execution |
| Environment |
+----------------+
10. Long-Term Vision¶
Our long-term vision is to build an open, extensible compliance platform that becomes the authoritative source of regulatory knowledge.
Future capabilities may include:
- Regulatory change management
- Automated impact analysis
- AI-assisted rule generation
- Metadata-driven report generation
- Data lineage visualization
- Regulatory digital twins
- Multi-jurisdiction support
11. What Success Looks Like¶
Success is achieved when:
- Regulatory knowledge is no longer trapped in code.
- Validation rules can be generated automatically.
- Banks can adopt new regulations faster.
- Compliance assets become reusable.
- Regulatory intelligence becomes a strategic asset.
Ultimately, CDAP aims to become the bridge between regulatory knowledge and execution technology.
12. Project Motto¶
Define Once. Generate Everywhere.
CDAP transforms regulatory knowledge into reusable, executable assets—allowing organizations to focus on compliance outcomes rather than implementation mechanics.