We’ve introduced a new Customizer option called Skip error screen.

This allows partners to bypass Consent UI error screens entirely and redirect users directly back to their application when a connection fails or when any error is returned from the data holder. In these cases, partners can handle the error using the jobs endpoint and related error responses.

This is particularly useful for partners who want full control over the failure experience. Instead of users being shown a generic Consent UI error screen, they remain within the partner’s flow and can present a consistent, branded experience even when something goes wrong.

Supported scenarios:

  • DCR errors
  • Connection failures returned during verify-credentials flows

Additional details:

  • Supported for WEB and Open Banking flows
  • Requires Redirect URL configuration
  • Independent from existing Skip success screen and Allow multiple connections options
  • Error information remains available through existing jobs endpoint responses

Documentation:

Consent UI Customisation

Customise UI

May 2026 introduces expanded Insights capabilities, including a unified multi-user endpoint, static reference data for Insight types, and a breaking fix to the Balance Verification response structure.

Create InsightNew

The new POST /insights endpoint generates an Expense‑to‑Income CDR Insight and supports requests for either a single user or multiple users (1–10). Single‑user requests return an individual insight, while multi‑user requests returns an aggregated result.

  • Endpoint: POST /insights
  • Supported Types: EXPENSE_RATIO_VERIFICATION, BALANCE_VERIFICATION, ACCOUNT_VERIFICATION, IDENTITY_VERIFICATION, INCOME_VERIFICATION
  • Multi-user: Multi-user requests (1–10 users) are currently supported only for EXPENSE_RATIO_VERIFICATION

Use Cases: Generate expense ratio, balance, account, identity, or income verifications across multiple users in a single API call.

List Insight TypesNew

GET /insights/types returns all supported CDR Insight types and the Insight-specific input schema each type expects. Records are pre-seeded per environment and serve as static reference data — no runtime creation or validation occurs.

  • Endpoint: GET /insights/types
  • Returns: type, id, name, description, supportMultipleUsers, dataSchema for each Insight type
  • Note: dataSchema reflects Insight-specific input only — does not include transport-level fields such as users or type

Use Cases: Discover available Insight types and their required input fields before constructing a POST /insights request.

Retrieve Insight TypeNew

GET /insights/types/{typeId} returns the definition of a single Insight type by ID. Designed for discoverability and input validation — returns the dataSchema for the requested type alongside its metadata.

  • Endpoint: GET /insights/types/{typeId}
  • Path Parameter: typeId — one of ACCOUNT_VERIFICATION, BALANCE_VERIFICATION, IDENTITY_VERIFICATION, INCOME_VERIFICATION, EXPENSE_RATIO_VERIFICATION
  • Error: 404 returned for unknown typeId values

Use Cases: Validate the required input shape for a specific Insight type before submitting a request, or surface type details in a partner-facing UI.

Balance Verification Response FixBreaking

The Balance Verification API response field accountNumber has been renamed to balance. The previous naming was misleading and caused confusion with Account Verification.

  • Changed Field: accountNumber → balance in BalanceInsightDataItem and AccountBalanceData schemas
  • Affected Endpoint: GET /users/{userId}/insights/{insightId} where insightType is balance

Use Cases: Consumers reading balance verification results must update their integration to reference the balance field instead of accountNumber.

These updates in May expand Insight generation to support multi-user requests, introduce discoverable reference endpoints for Insight types, and resolve a misleading field name in the Balance Verification response.

Improved validation errors in Customise UI (Dashboard)

We’ve improved how validation errors are handled when configuring application policies in the Customise section.

Previously, the Save button was disabled when required fields were missing, without clearly indicating what needed to be fixed. This often led to trial and error during setup.

Now, when you try to save with incomplete or invalid fields:

  • Clear, descriptive error messages explain what’s wrong
  • Specific fields that need attention are highlighted
  • Relevant sections and tabs show visual error indicators
  • Hovering over the Save button reveals why submission is blocked

These changes make it easier to identify and fix issues quickly, leading to a smoother setup experience.


Basiq will no longer be providing active support for the ANZ New Zealand connector (NZ00101).

The connector will remain available in its current state, however it is no longer under active maintenance and will not receive updates or fixes going forward. Partners who rely on this connector should be aware that connection success rates may be inconsistent and cannot be guaranteed.

What this means for you:

  • The ANZ NZ connector will remain visible and selectable within the platform
  • No ongoing break/fix work will be performed on this connector
  • Basiq will not investigate or remediate future connection failures related to this institution
  • Partners are encouraged to communicate with their end users about the potential for failed or unreliable connections to ANZ New Zealand

If you have questions, please reach out to Basiq Support.


March 2026 brings extended capabilities for financial data access, webhook monitoring, and granular permissions configuration.

Auth Links Validity ExtendedUpdate

Auth Links now remain valid for 30 days, allowing users to link and share data from multiple accounts across financial institutions within this period. Links expire automatically after 30 days or once users complete the disclosure flow.

  • Auth Link Expiry: 30 days or upon disclosure flow completion
  • Supported Actions: Link multiple accounts, share data with multiple institutions

Use Cases: Enable longer self-service financial data capture, reduce repeated consent requests, and allow multi-account linking in a single window.

Webhook Stats EndpointNew

The new GET /notifications/webhooks/{webhookId}/stats endpoint provides real-time monitoring of webhook delivery. Track performance and troubleshoot delivery issues directly through the API.

  • Endpoint: GET /notifications/webhooks/{webhookId}/stats
  • Response: Returns delivery status, success/failure counts, and timestamps

Use Cases: Monitor webhook success rates, identify failures, and ensure timely notifications for financial events.

Expanded Permission SetsUpdate

Permission sets now support additional endpoints across Events, Merchants, Reports, Users, Enrich, and Webhooks categories, allowing partners to enable or disable access via the Dashboard to prevent unexpected 403 errors.

  • Events & Jobs: GET /events/{eventId}, POST /jobs/{jobId}/mfa
  • Merchants: GET /merchants, GET /merchants/{merchantId}
  • Reports: GET /reports/types/{reportTypeId}, DELETE /reports/{reportId}, GET /reports/{reportId}/transactions
  • Users: POST /users/{userId}/connections/{connectionId}/purge, GET /users/{userId}/identities, POST /users/{userId}/insights/expense-ratio
  • Enrich: GET/POST /enrich/jobs, GET /enrich/jobs/{id}
  • Webhooks: GET /notifications/webhooks/{webhookId}/stats

Use Cases: Control access to sensitive endpoints, manage user-level permissions, and reduce API errors due to insufficient permissions.

These updates in March enhance user access, monitoring, and control across Basiq’s APIs, giving partners more flexibility and insight into their integrations.