New root structure​

The FlowOutput payload is now split into two top-level objects:

• member — Member financial profile and open banking analysis data
• application — Loan application form data submitted by the borrower

Member data (member)​

This is an entirely new section providing rich financial context derived from the member's connected accounts:

• Profile — demographics, income summary, onboarding objectives, and employment info
• Serviceability — detected and declared income/expenses, HEM and HPI benchmarks, housing floor calculations, guardrail results, and repayment capacity
• Risk analysis — gambling, ATM withdrawal, and SACC loan risk metrics with flagged transaction streams
• Streams — grouped transaction streams with BrightMatch categorisation, cadence detection, statistical summaries, and merchant identification
• Accounts — all connected accounts with balance history, 90-day metrics, and Open Banking status
• Transactions — individual transactions with provider and BrightMatch category classifications
• Net capacity components — income and expense breakdown used for net capacity calculation
• Identity — optional member identity verification (drivers licence or passport)
• memberId — unique WeMoney member identifier

Application details (application)​

The application section has been updated with several structural changes from the previous version:

• Employment — income fields (amount, isPreTax, frequency) are now flattened directly onto the employment object instead of nested under an income sub-object. The status field is renamed to type, and duration is replaced by startDate (YYYY-MM format).
• Residence — duration is replaced by startDate (YYYY-MM format), and the state field is simplified (e.g. "NSW" instead of "AU-NSW").
• Identity — the verificationType field is renamed to type with lowercase values ("passport", "driversLicense").
• Loan & Expense amounts — amount fields are now typed as strings to match form submission values.
• referenceId — new optional field for the external lender's reference ID.
• Removed fields: applicationType, applicationId, userId, liabilities, otherIncome, previousEmployment, previousResidence.

New API endpoint​

Flow now includes an API for retrieving application data programmatically:

• GET /flow/v1/applications/{applicationId} — returns the full FlowOutput for a given application
• Authentication uses the same OAuth2 Client Credentials flow as Relay, with the flow/application:read scope

See the updated Flow documentation for the full schema reference.

SFTP as an alternative to webhooks​

The primary and preferred method for sending data back to BrightMatch remains the Relay webhook API, which provides a standardised schema and real-time delivery. However, we recognise that not all lending partners are able to integrate with an HTTP webhook directly.

For these partners, we now offer a dedicated SFTP server where outcome files can be uploaded. We accept any reasonable file format (CSV, JSON, Excel, etc.), though we encourage aligning with the standard Relay schema where possible.

Getting started​

Connection details and a CLI example are available in the Relay (SFTP) documentation. To request SFTP credentials, contact your BrightMatch integration representative.

BrightMatch Flow centralizes all application data models and schemas into a dedicated product accessible at /flow. This provides developers with a single reference point for understanding the structure of loan application data exchanged between BrightMatch and lending partners.

BrightMatch Relay simplifies webhook integration by focusing exclusively on status notification endpoints, available at /relay. Lenders send status updates to BrightMatch using POST /relay/v1/status. As part of this launch, we've streamlined the webhook implementation by removing HMAC signature authentication requirements and simplifying the payload structure. The webhook payload now requires only a status field, with optional fields for decline reasons and timestamps.

Our documentation has been rebuilt around these two products, replacing the previous single API specification with focused, product-specific documentation. The navigation reflects this new structure, guiding developers through data models first (Flow) before implementation details (Relay).

These changes maintain full backward compatibility while establishing a foundation for future platform enhancements. Developers can access the new documentation at /flow for BrightMatch Flow and /relay for BrightMatch Relay.

This is where we'll share important updates, feature releases, and other news about BrightMatch. Check back soon for more content!