Open Finance

Extending data portability beyond payment accounts

A wider financial picture

Open finance extends customer-directed financial-data access beyond the payment-account scope associated with many open-banking frameworks. It can include lending, savings, investments, pensions or insurance, depending on the market and arrangement. A consumer-data framework may also cover non-financial sectors; that does not make an energy provider a bank.

The potential benefit is a joined financial picture for a customer or a defined use, such as affordability assessment. The risk is a joined set of sensitive information used without suitable authority, accuracy or purpose controls. More data does not inherently produce a better or fairer decision.

Scope is specific to each product

Identify the data holder, eligible recipient, customer's authority, fields and permitted use for each product family. Account ownership, authorised-user status and joint mandates can differ. Permission for a payment account does not automatically cover a pension or another person's borrowing.

Mandatory access and voluntary commercial sharing need separate treatment. A commercial contract does not override privacy, confidentiality or product restrictions. A mandate to disclose specified data does not authorise unlimited additional sharing. Define the actual scope and legal basis with the responsible legal and compliance owners.

Data meaning and provenance

Loan principal, accrued interest, arrears and available credit describe different amounts. An investment valuation needs an as-of time, pricing source and relevant unsettled positions. A pension projection is not necessarily a current withdrawable balance. A recipient should not combine such values into one apparently precise total without explaining their meaning.

Publish product-specific definitions, quality limitations and source attribution. Pending transactions, joint liabilities and missing data must remain recognisable. A null value is not zero, and a transaction inferred to be income is not confirmed employment income.

If a source defect is found, establish which recipients and decisions may be affected. Correct the source and communicate through the agreed incident route. A corrected field does not automatically reverse a lending decision already made using the earlier value.

Permission and downstream use

Permission should describe the product and use in language the customer can understand. The appropriate records, duration, renewal and withdrawal processes depend on the framework. Sharing for budgeting does not inherently permit marketing, model training or a lending decision.

Recipients need controls over storage, access, onward disclosure and retention. Withdrawing future sharing differs from requesting deletion of previously collected information; applicable law may require some records to remain. Dashboards should explain the actual effect of the customer's action rather than imply that every copy has vanished.

Worked example: assessing income

In this fictional journey, Sravanthi permits a lender to obtain specified transaction data for an application. A recurring transfer resembles salary but is money moved between her own accounts. The lender checks classification uncertainty and relevant evidence instead of treating the pattern as verified employment income.

The data holder supplies faithful transaction facts and provenance. The lender owns its interpretation and decision under the applicable arrangement. That practical division of work does not establish a universal legal liability allocation. Both parties need evidence to investigate a challenged decision.

Read access does not imply action authority

An investment feed showing holdings does not give the recipient authority to trade. Loan-data access does not permit a change to repayment instructions. Action initiation requires its own authority, controls and applicable framework. Assess it as a separate capability even where the same interface family supports it.

Governance and sources

Measure scope enforcement, field accuracy, stale data, withdrawal propagation, incident handling and customer understanding. Review recipients and purposes as the catalogue expands. Test each product family's error and withdrawal path rather than assuming payment-account tests cover it.

Australia's CDR overview and data-holder compliance guidance illustrate customer-directed sharing and privacy safeguards across defined sectors. Coverage evolves; use current local instruments for implementation rather than treating all financial products as already mandated everywhere.

Takeaway

Open finance widens the information boundary. Every added product needs clear authority, accurate semantics and controls over the recipient's actual use.

Continue to API Products.