Getting Started with Open Banking APIs: A Developer Guide

Open banking APIs let you access bank account data — balances, transactions, account details, and identity information — with the account holder's consent. Whether you're building a personal finance app, a lending product, an accounting integration, or a payment verification flow, open banking is the data layer underneath.

This guide covers the core concepts, architecture patterns, and practical steps for developers getting started with open banking API integration.

Core Concepts

How Open Banking Works

Open banking is a framework where banks (data holders) provide API access to customer data, with the customer's explicit consent, to authorised third parties (data recipients). The key participants are:

• Data holder — the bank or financial institution that holds the consumer's account data and exposes it via APIs.
• Data recipient — the application (your product) that accesses the consumer's data with their consent.
• Consumer — the account holder who authorises data sharing.
• Regulatory body — the authority that sets the rules, standards, and accreditation requirements (e.g., ACCC in Australia, FMA in New Zealand, FCA in the UK).

Consent-Driven Access

Every data access request requires explicit consumer consent. The consumer must:

1. Understand what data will be shared
2. Authenticate with their bank
3. Approve the specific data scope
4. Be able to revoke consent at any time

This is fundamentally different from screen scraping, where consumers share their banking credentials. With open banking, credentials are never exposed to the third-party application.

Standardised APIs

Open banking APIs follow published standards that define endpoints, data models, authentication methods, and error handling. In Australia, this is the Consumer Data Standards. In the UK, it's the Open Banking Standard. New Zealand follows a similar framework. While the specifics vary by market, the architecture patterns are consistent.

Authentication and Security

Open banking APIs use financial-grade security. The authentication flow typically follows this pattern:

The Consent Flow (Simplified)

1. Your app creates a consent request — specifying what data you need (accounts, transactions, balances) and for how long.
2. Consumer is redirected to their bank — they see the bank's login page and authenticate using their normal banking credentials (including any MFA).
3. Consumer reviews and approves — the bank shows them exactly what data will be shared, and with whom.
4. Redirect back to your app — with an authorisation code.
5. Your app exchanges the code for tokens — an access token (short-lived) and a refresh token (longer-lived).
6. Use the access token to call APIs — include it in the Authorization header of your API requests.

The security standard used is FAPI 1.0 Advanced (Financial-grade API), which is built on top of OAuth 2.0 and OpenID Connect with additional security requirements like mutual TLS (mTLS), signed request objects, and Proof Key for Code Exchange (PKCE). FAPI 2.0 is under development and may be adopted in future iterations.

Token Management

Access tokens typically expire after 5–60 minutes. Use the refresh token to obtain new access tokens without requiring the consumer to re-authenticate. Refresh tokens last for the duration of the consent (up to 12 months in most markets). When the consent period expires, the consumer must re-authorise.

Key API Endpoints

While specific endpoints vary by standard, the core data model is consistent across markets:

Accounts

GET /accounts
GET /accounts/{accountId}

Returns a list of the consumer's accounts and detailed information about each account, including account type, name, balances, and identifiers (BSB + account number in Australia, sort code + account number in the UK).

Transactions

GET /accounts/{accountId}/transactions?oldest-time=2025-01-01&newest-time=2025-12-31

Returns transactions for a specific account within a date range. Supports pagination for large result sets. Each transaction includes amount, description, date, type, and status.

Balances

GET /accounts/{accountId}/balance

Returns the current and available balance for an account. Useful for real-time balance checks before payment initiation.

Customer / Identity

GET /common/customer

Returns the authenticated customer's profile information — name, contact details, and in some markets, address. This is useful for identity verification and pre-filling application forms.

Data Models

Open banking APIs return JSON responses with standardised structures. Here's what a typical transaction object looks like:

{
  "transactionId": "tx-12345",
  "accountId": "acc-67890",
  "isDetailAvailable": true,
  "type": "PAYMENT",
  "status": "POSTED",
  "description": "WOOLWORTHS 1234 MELBOURNE",
  "postingDateTime": "2025-12-01T10:30:00+11:00",
  "amount": "-45.67",
  "currency": "AUD",
  "reference": "VISA PURCHASE"
}

And a typical account object:

{
  "accountId": "acc-67890",
  "displayName": "Everyday Account",
  "productCategory": "TRANS_AND_SAVINGS_ACCOUNTS",
  "productName": "Smart Access",
  "isOwned": true,
  "maskedNumber": "xxxx1234",
  "balances": {
    "currentBalance": "1234.56",
    "availableBalance": "1200.00"
  }
}

Common Integration Patterns

Pattern 1: One-Time Data Fetch

For use cases like loan applications or account verification, you may only need to fetch data once. The flow is: get consent → fetch accounts → fetch transactions for a date range → process data → done. The consent can be short-lived (one-time use or hours).

Pattern 2: Ongoing Data Sync

For personal finance apps or accounting integrations, you need continuous access. The flow is: get consent (longer duration, e.g., 12 months) → initial data fetch → periodic polling for new transactions → refresh tokens as needed. Most integrations poll daily, but some use cases require more frequent updates.

Pattern 3: Real-Time Checks

For balance verification before payments or real-time affordability checks, you need low-latency access. The flow is: maintain active consent → call balance endpoint at decision time → make decision → proceed. Latency matters here — choose an API provider with fast response times.

Building vs. Using a Platform

You have two main approaches to integrating open banking:

Direct Integration

Build direct connections to bank APIs yourself. This means:

• Obtaining accreditation (CDR accreditation in Australia, FCA registration in the UK, etc.)
• Implementing FAPI 2.0 security (mTLS, signed JWTs, PKCE)
• Building consent management flows
• Connecting to each bank individually
• Managing token refresh, error handling, and data normalization across banks
• Maintaining ongoing compliance with evolving standards

This gives you maximum control but takes months of engineering time and ongoing compliance effort.

Managed Platform

Use an open banking API platform that handles accreditation, security, consent, and bank connectivity for you. You integrate with a single API and get access to all connected banks. This approach lets your team focus on building product features rather than infrastructure.

The trade-off is less direct control over the bank connection layer, but for most teams, the speed and simplicity outweigh this. You can go from zero to live in days instead of months.

Market-Specific Notes

Australia

Open banking in Australia is regulated under the Consumer Data Right (CDR). Accreditation is through the ACCC. The Consumer Data Standards define the API specifications. Major banks have been live since 2020, with non-bank lenders joining from 2026. Energy data is also available through CDR.

New Zealand

New Zealand has moved to regulated open banking under the Customer and Product Data Act. The major banks are participating, and the API standards are closely aligned with Australia's CDR standards, making cross-Tasman integration relatively straightforward for teams operating in both markets.

United Kingdom

The UK's Open Banking Implementation Entity (OBIE) was one of the earliest open banking frameworks globally. The UK has the most mature open banking ecosystem, with over 15 million consumers using open banking-enabled products. The Data Protection and Digital Information Act extends the framework further.

Other Markets

Open banking is expanding globally — the EU's PSD3 has reached provisional political agreement and is expected to enter into force in 2026, Brazil has a comprehensive Open Finance framework, and markets across Asia and Latin America are implementing their own standards. The architectural patterns described in this guide apply across markets, though the specific standards and accreditation requirements differ.

Getting Started Checklist

1. Define your use case — what data do you need, for how long, and for what purpose?
2. Choose your approach — direct integration or managed platform?
3. Set up a sandbox — test against mock data before connecting to live banks.
4. Build the consent flow — integrate the redirect-based consent flow into your user journey.
5. Implement data handling — fetch, store, and process the data according to your use case.
6. Handle edge cases — token expiry, consent revocation, bank downtime, and data quality issues.
7. Go live — connect to production bank APIs and start serving real users.

Fiskil provides open banking APIs for developers in Australia and New Zealand. Access bank accounts, transactions, identity data, and energy data through a single integration. Read our API documentation.