BIQH validations easily explained
Table of Contents
1. What is a validation and why is it important?
A validation is a defined check that confirms whether incoming market data complies with agreed rules before being used by downstream applications. Validations are essential for maintaining the integrity, reliability and usability of your data. They act as safeguards, preventing incorrect, incomplete or non-compliant data from entering critical business processes. This protects against operational risks and ensures that decision-making, reporting and regulatory compliance are based on accurate and trusted information.
The purpose of validations is to:
- Ensure data quality so that analytics, reporting and decision-making are based on accurate, consistent information.
- Prevent operational errors by stopping incorrect or incomplete data before it flows into critical processes.
- Maintain compliance with regulatory requirements, vendor contracts and internal governance policies.
- Reduce downstream remediation costs by catching issues early rather than fixing them later.
2. BIQH validation types
Validations are organised into three tiers, separating container checks, content checks and process-level monitoring. The diagram below illustrates this process, using traffic-light indicators to show how data moves through the platform:
- Green: Validation passed, process continues downstream without interruption.
- Orange: Passed but flagged, requires human review (for example via the Four-Eyes module).
- Red: Hard stop. The issue must be resolved, either by your team or by BIQH as part of standard or managed services, before processing can continue.
Tier 1 File structure validations (container level)
Applied before any content is read, these checks ensure that files are technically sound and match the feed’s expected schema.
Examples:
- Required headers are present in accordance with the feed specification.
- File format is supported (File format matches the expected type, such as TXT, XML, CSV, XLSX, JSON or API.
- In case of multiple files, all expected data is present.
Prevents malformed files from entering the process, ensuring safe downstream parsing. Green, orange and red status indicators determine whether the data advances to Tier 2.
Tier 2 Data content validations (record level)
Applied after the file passes structure checks, these focus on the fields and records themselves.
| Validation group | Purpose | Example |
| Format and Data Type Validation | Checks syntax, pattern and type | ISIN per ISO 6166; valid currency codes |
| Completeness and Mandatory Field Checks | Ensures essential attributes are present | Price and Price Date not null |
| Allowed Values and Reference Data Validation | Confirms values exist in approved code lists | CFI per ISO 10962; valid MIC codes |
| Range and Threshold Validation | Ensures values stay within realistic limits | Price change within tolerance |
| Cross-Field Consistency and Business Logic Rules | Applies logical conditions across fields | IF/ELSE dependencies within a record |
| Referential Integrity and Cross-Record Checks | Prevents duplicates and enforces unique keys | All position records’ Instrument IDs must exist in the Security Master |
| Cross-Source Reconciliation Checks | Compares data across vendors | Price comparison between vendors |
| Regulatory and Compliance Validations | Applies policy-driven rules | NAV not older than two days; Four-Eyes approval |
Purpose: Ensures the content itself is correct, complete, consistent and compliant. Orange or red results here can trigger the Four-Eyes review process or escalation to BIQH’s managed services.
Tier 3 Monitoring validations (process level)
Observability controls that track the health, timeliness and delivery of both inbound and outbound data feeds. They do not assess the correctness of the content but ensure that data arrives and is ready for processing.
Examples:
- Timeliness checks verifying data arrives by the agreed cut-off time or expected frequency (for example hourly).
- Operational readiness checks confirming files or API responses are available for ingestion.
- Exception dashboards surfacing warnings, late arrivals or missing data during collection and validation.
Purpose: Assures operational readiness so that validated data can flow to downstream applications without interruption. Once all validations are green, the data proceeds through the BIQH platform and is delivered to target applications.
3. Flexible validation creation
With our flexible GUI, we can create any type of validation you require, even if it is not listed above. If there is a specific check you expect but do not see here, let us know and we will configure it for you.
For any other questions, or to explore our capabilities in more detail, please contact us or download our factsheet.
