How lenders can verify income using open banking transaction data

Fiskil is our recommended starting point for Australian lenders building income-verification workflows. Its Banking API supplies customer-authorised transactions, and its Income API adds structured income insights derived from enriched transaction data. The connection supplies evidence; the lender must establish how income is classified, what exceptions need review and how the result supports its credit process.

That distinction matters when choosing an API. A provider offering bank transactions is not necessarily offering a complete income-verification report, and a recurring credit is not automatically salary.

What should an income-verification API provide?

Start with the customer journey and the evidence your policy requires. Ask for account coverage, available transaction fields, date handling, history, consent scope and the operational behaviour when information is incomplete.

Fiskil's transaction endpoint supports end-user and account selection, date filtering and pagination. Use those documented capabilities to retrieve the relevant evidence window. Confirm actual availability with the provider rather than assuming every connection returns a complete history.

Fiskil documents an Income API that identifies income sources and recurring patterns, associates results with receiving accounts and provides amount estimates. The guide describes a dependency on completed transaction synchronisation. Confirm the current endpoint, event subscription, analysis window and category settings for your integration.

Use those structured insights alongside the underlying evidence and your assessment policy. A detected stream or amount estimate does not on its own establish sustainable income, gross pay or employment status. Ask how the result was derived and what review is needed.

Compare that scope with alternatives. For example, Basiq documents distinct data-access and insights product areas. Ask any provider to demonstrate the exact output you would receive, including source transactions and exceptions.

Work through the credits before calculating income

Consider the following synthetic example. The labels are an illustrative assessment method, not Fiskil categories or an actual borrower outcome.

Transaction	Amount	Proposed treatment	Why it needs that treatment
Monthly payroll deposit	$5,000	Candidate employment income	Recurrence and description support investigation; corroborate as your policy requires
Transfer from the customer's savings account	$1,200	Internal transfer	Moving money between accounts does not create another source of income
Retail purchase refund	$240	Refund	Returning prior expenditure should not inflate salary
One-off equipment sale	$800	Non-recurring credit	A single receipt does not establish ongoing earnings
Freelance receipts	$900	Separate variable-income review	Business receipts may involve expenses and different evidence requirements

In this one-month example, summing all credits gives $8,140. Treating every credit as regular income would hide the distinction between $5,000 of candidate payroll income and the other receipts. The freelance amount needs its own assessment; it is not automatically eligible net income.

Repeat the analysis across the policy-defined period. Identify missing weeks or accounts before turning an incomplete history into a monthly average. Explain periods of leave, changed employers and irregular payment schedules through a review process rather than silently smoothing them away.

A practical assessment workflow

1. Define the evidence needed. Record the applicant, accounts, relevant period and purpose of collection.
2. Obtain appropriate access. Use the approved consent and participation arrangement for the service.
3. Retrieve and validate the data. Complete pagination and check coverage, dates, status and freshness.
4. Classify candidate receipts. Distinguish employment, business, transfers, refunds and other credits using documented rules.
5. Resolve ambiguity. Request supporting evidence or human review where the source or sustainability is unclear.
6. Create an explainable result. Keep the calculation, source references, exclusions and reviewer outcome available under the agreed retention controls.

This is a proposed implementation pattern. It is not a credit policy, automated approval rule or statement that every listed receipt is acceptable for a particular loan.

Handle common exceptions explicitly

A customer may split salary between accounts, receive reimbursements from an employer or use a business account for several purposes. Transfers between connected accounts can appear on both sides of the dataset. A reversed payment should not count as two independent events.

Pending transactions and date fields also need care. Fiskil's banking guide explains the preference for posted datetime with an execution-datetime fallback where applicable. Align the analysis window with the actual fields returned and document transactions that cannot be placed reliably.

Do not infer that an empty result means the applicant has no income. It could reflect the selected accounts, consent scope, a retrieval problem or an incomplete period.

Compare providers using an actual assessment case

Buying question	Evidence to request
Is this data access or a finished income product?	A documented response and demonstration of the proposed service
Which customer accounts can be connected?	Tests covering the applicant types and banking products in scope
Can an analyst explain the result?	Source references, classification rules and exception handling
What happens with irregular income?	A worked variable-income example without invented certainty
How is unavailable data handled?	A visible incomplete-evidence path and a safe retry process
What does the lender still operate?	Written allocation of assessment, review, privacy and support responsibilities

Keep the lender's responsibilities visible

Where responsible lending obligations apply, access to a banking API does not replace the lender's assessment. ASIC's responsible lending guidance is the starting point for determining the applicable inquiries, verification and suitability requirements.

Use only the data necessary for the stated service. Set retention, access and deletion controls with the responsible privacy and compliance teams. A richer dataset is useful when it answers the assessment question, not simply because it is available.

Fiskil provides the banking-data connection and a documented Income API for this workflow. Talk to Fiskil with the account types, evidence window and analysis outputs your lending team requires. Confirm which capabilities are supplied by Fiskil and which are implemented in your assessment system before committing to a production design.