Following a C 07.00 figure back to COBOL

An auditor selects a credit risk exposure amount in COREP template C 07.00 and asks where it came from. The reporting team finds the table feeding the return. Then an intermediate table. The amount reflects a currency conversion, but the conversion rule still needs to be located.

Consider an illustrative case where two COBOL programmes handle the conversion. The first reads the outstanding balance from DB2 and retrieves an exchange rate. The second converts the balance before aggregation. Explaining the reported figure means following the columns used and checking the relevant instructions, including the conditions governing the calculation.

For a UK reporting team, the same exercise can use a balance converted into sterling. The reporting currency changes. The evidence needed to explain the conversion does not.

An arrow between “loans” and “regulatory reporting” does not show which exchange rate was selected. Nor does it explain what happens when a currency is missing from the reference data. Those steps need to be available for inspection.

Separating BCBS 239 principles from detailed ECB expectations

The 2013 BCBS 239 principles address data architecture, accuracy and completeness, among other areas. Paragraph 39 expects banks to document and explain their risk data aggregation processes, whether automated or manual. Data lineage helps support that explanation. Basel Committee, January 2013, principles 2 to 4 and paragraph 39.

The ECB’s May 2024 guide explicitly expects complete, current attribute-level lineage from capture through transformation for in-scope risk indicators and their critical data elements. It does not impose new requirements. ECB, introduction and section 3.4.

UK readers should distinguish this ECB guidance from the requirements applicable to their own entities. For a group operating across the UK and the EU, the assessment should identify the relevant supervisory framework for each entity.

In our example, lineage connects the reported figure to its source data and makes each calculation available for review. A system overview alone cannot explain the conversion.

Column-level lineage shows how the amount changes

A DB2 table may contain both the original balance and the converted amount. Table-level lineage shows a dependency between objects. It does not establish which field contributes to the reported figure.

The trace therefore needs to connect the reporting cell to its aggregation, then follow each transformation back to the source column. Here, that includes the currency field and the origin of the exchange rate. The filters selecting which balances enter the calculation also need to be examined.

Copybooks define the data structures used by the COBOL programmes. JCL helps establish where those programmes sit in the batch processing sequence. Reading these alongside DB2 access instructions provides more evidence than a programme name alone.

Code has limits as evidence. It describes possible processing logic. To substantiate a particular submission, the bank also needs to establish which version ran and which data and parameters it used. Lineage extracted from today’s code cannot, by itself, prove last quarter’s figure.

Keep declared links separate from links found in code

If a programme changes without a corresponding catalogue update, the documented link may no longer match the processing performed. The destination table can retain the same name throughout.

A declared link still has value. A business owner can explain why a data item belongs in an indicator. That explanation should remain identifiable as a declaration. A link extracted from code provides a different form of evidence, allowing the reviewer to inspect the transformation instructions.

Keeping the two distinct makes unverified connections easier to locate. Where a connection rests on a person’s explanation, the record should say so and identify the evidence still needed.

Using a separate parser for each technology also requires checks at the boundaries. Each parser may describe its own part without establishing the handover to the next system. Test the full path from the reporting cell, including interfaces between technologies.

Connect the technical calculation to its business definition

Technical lineage explains how one column feeds another. The business view connects that transformation to a definition and the reports that use it. Both views need to refer to the same data.

In this example, the currency conversion instructions need to be compared with the business rule governing the balance. Risk should be able to review that comparison with IT. Regulatory Reporting should be able to locate the affected cell without reading every COBOL instruction.

Responsibilities may be spread across Risk, Finance and IT. Each team can hold part of the explanation. Where the connections are undocumented, an audit query requires the teams to reconstruct the path together.

For COREP or FINREP work, start with a return that was actually submitted. For each cell under review, identify who owns its definition and who owns the processing. Any discrepancy can then be assigned to people who have a specific rule and calculation to compare.

Assemble evidence for the reporting date under review

I recommend testing the evidence pack against a submitted amount. The following checks are practical suggestions, not an exhaustive regulatory checklist.

Locate the figure. Identify the cell, reporting date and legal entities covered.
Inspect the transformation. Show the source columns and programme instructions explaining the calculation.
Explain the population. Provide the inclusion criteria and exclusions applied before aggregation.
Account for manual interventions. Connect each adjustment to the affected amount and its supporting explanation.
Provide control results. Include results for the reporting date under review and any unresolved exceptions. Check whether the data was available in time.
Identify the version executed. Distinguish the processing used for the submission from the code available today.

The auditor should be able to move from the figure to the evidence explaining it. Access to a diagram without the underlying transformations leaves part of that review unfinished.

Trace a data issue to the affected returns

Suppose the exchange rate is missing in our example. A control flags the affected column. Lineage then identifies dependent transformations and potentially affected reports. Quantifying the impact still requires the data used for that reporting date.

A single quality score can conceal differences between returns. One report may have complete data while another has gaps. Accuracy and integrity need separate checks. Depending on the data, uniqueness and consistency checks may also be useful. The review must also establish whether the data arrived in time for the reporting process.

Section 3.5 of the ECB guide covers controls throughout the in-scope data chain, quality indicators with tolerances, and documented correction procedures. ECB, May 2024, section 3.5.

Make existing code available for inspection

Vokse analyses code as it exists, including COBOL, JCL and Copybooks, alongside DB2, relational databases and Salesforce. Its reverse engineering draws on 25 years of R&D. AI sorts and connects the findings.

Lineage reaches column level, distinguishes discovered links from declared links and opens transformations down to the relevant lines of code. It connects these paths to business processes and reports, with continuous accuracy and completeness controls and dedicated auditor access.

The BCBS 239 self-assessment takes 3 minutes and covers 8 questions. Results are immediate, with no email required.

FAQ

How does data lineage support the BCBS 239 principles?

It helps explain data origins and aggregation, supporting accuracy and completeness. Paragraph 39 addresses the documentation of aggregation processes. Basel Committee, 2013. The explicit attribute-level lineage expectation appears in the ECB guide, section 3.4.

Do banks need technical or business lineage?

The two serve complementary purposes. Technical lineage exposes dependencies and transformations. Business lineage connects those operations to definitions and reports. Bringing them together helps reviewers compare the implemented calculation with the intended rule.

Why trace data at column level?

Two columns in the same table may undergo different processing. Column-level lineage identifies the field actually used and the transformation contributing to the final amount.

How can a bank document lineage for a FINREP cell?

Start with the cell and reporting date. Follow the aggregation rules back to the source columns and document any adjustments. Then connect the control results, input data and executed programme versions to that submission.

BCBS 239 data lineage for tracing a COREP figure to source