Structuring Open Banking Data Exports for a Documentation File

Open banking exports deliver transaction data through an authorised API connection rather than through a PDF or CSV the customer downloads from the bank's portal. The export reaches the documentation file through a different route, and the file records that route alongside the data itself rather than treating the two as equivalent.

The consent basis is the first thing recorded. Open banking access is granted by the customer through a regulated provider for a defined period and a defined scope. The file records the provider, the scope, the date the consent was granted, and the date the consent will expire or has expired in the absence of renewal.

Categorisation applied by the provider is treated as derived data, not source data. A transaction labelled by the provider as groceries, transport, or utilities reflects the provider's classification rules, not a fact the bank confirmed. The file records both the raw description and the provider's category so a reviewer can challenge either layer.

Account aggregation across institutions is a common open-banking pattern, and the file preserves the institution of origin for every entry. A merged feed that loses the originating bank reduces the evidential value of the data because the chain back to the source institution can no longer be traced from the export alone.

Refresh frequency and data freshness are recorded. An open-banking feed pulled once and not refreshed produces a snapshot rather than a continuous record, and the documentation file states the snapshot date so that a reviewer reading the file weeks later understands what the data does and does not show about subsequent activity.

Where the provider's terms allow it, the engagement retains the raw API responses alongside the structured view. The raw responses are the most defensible artefact because they show exactly what the bank delivered to the provider, with timestamps and signatures intact, before any downstream processing changed the shape.

Where consent is withdrawn or the provider's access fails, the file records the gap explicitly with the date and the reason. An incomplete feed is recorded as incomplete rather than backfilled from an earlier export, because backfilling without a new authorised pull cannot be evidenced as current data.

Our scope is to structure exports the client authorises through a regulated open-banking provider. We do not scrape bank portals, do not store credentials, and do not extend access beyond the consent the client granted. The deliverable is a structured file describing what the authorised feed delivered.