Financial reporting pipelines don't have a testing problem — they have a contract problem

The gap nobody names

Walk into a data engineering team at a bank or insurer, and you'll find tests. Usually plenty of them. Schema checks, row-count assertions, null validations. The pipeline goes green, the report ships, and the compliance officer signs off.

Until it doesn't. Until someone notices that a transformation quietly dropped a product category three months ago, or that a rounding convention changed between two DBT models without anyone realising it had business significance.

The tests were passing. The business expectation was violated. These are not the same thing.

What BDD actually changes

Behaviour-Driven Development is often introduced as a testing methodology. That framing misses the point — especially in data contexts.

BDD's actual contribution is a forcing function for making implicit domain knowledge explicit before any code is written. When you describe expected behaviour in Gherkin — Given, When, Then — you are obliging a business analyst and an engineer to agree, in writing, on what a transformation is supposed to mean. Not just whether it runs.

In financial reporting, that distinction is not a nice-to-have. It's an audit requirement.

What this looks like in DBT

DBT's test architecture maps onto BDD naturally. A schema test expresses a constraint. A singular test expresses a scenario. The gap is usually that teams write their tests after the model, inferring constraints from the implementation rather than deriving the implementation from stated requirements.

The reversal matters:

# Not this — a post-hoc constraint check
models:
  - name: regulatory_capital_report
    columns:
      - name: exposure_amount
        tests:
          - not_null

# But this — a named expectation with business provenance
tests:
  - name: exposure_amount_includes_off_balance_sheet_items
    description: >
      Per Basel III Article 111, off-balance-sheet items must be
      converted to credit exposure equivalents before aggregation.

The second form is a contract. The first is a guard rail. Both have their place; only one of them tells a regulator what you intended.

The platform angle

This matters to platform engineering because data pipelines in regulated industries are shared infrastructure. Multiple product teams consume the same transformation layer. When the logic is implicit — when the "why" behind a transformation lives in a Jira ticket from 2019 and the memory of one senior analyst — the pipeline cannot safely evolve.

Codifying the business rules as BDD specs doesn't just improve test quality. It transforms the pipeline from a black box that happens to produce correct output into a documented contract that anyone can challenge, verify, and extend. That's the difference between infrastructure that teams depend on because it works and infrastructure that teams can rely on because they understand it.

The full implementation — including a working DBT project with BDD-style tests wired to real financial reporting scenarios — is on GitHub.