Partner notice:
Paynetics now supports an OCT balance model that does not require a dedicated pre-funded OCT balance. This article explains how the dynamic balance model works, how it differs from the existing pre-funded model, and which use cases are supported.

This model is designed for merchants with active acquiring activity through Paynetics. Instead of maintaining a separate OCT account, OCT payout capacity is calculated dynamically from acquiring activity and the merchant's approved commercial setup.

Overview

Under the existing OCT setup, merchants maintain a separate, dedicated OCT account that must be funded before payouts can be processed. Funds may be transferred to that account through SEPA, SEPA Instant, Faster Payments or BISERA. A configured OCT Settlement Split percentage may also redirect part of acquiring settlement into the dedicated OCT account. When the dedicated balance is depleted, OCT processing is blocked until funds are restored.

What changes for partners:
the OCT API remains largely the same, but the balance field is no longer required for this model.

How the Dynamic Balance Model Works

With the dynamic balance model, OCT transaction capacity is linked to the merchant's acquiring activity and approved commercial setup. Acquiring authorisations increase available capacity, while OCT payouts decrease it. The system effectively nets acquiring inflows and OCT outflows in real time.

There is no dedicated OCT balance account to pre-fund before sending payouts.
Available payout capacity is determined dynamically from the merchant's acquiring activity.
Acquiring authorisations increase available capacity; OCT payouts consume or decrease the available capacity.
Paynetics performs real-time netting between acquiring inflows and OCT outflows.
OCT processing can continue while the net balance remains positive or within an approved overdraft limit.

If the net balance is exhausted and no overdraft is configured, further OCTs are declined until additional acquiring volume restores capacity.

This approach helps merchants avoid separate balance management while keeping OCT processing aligned with their approved operating model.

Comparison with the Pre-Funded OCT Model

Feature	Pre-Funded OCT Model	Dynamic Balance Model
Dedicated OCT account	Required	Not required
Funding method	Funds are deposited into the dedicated OCT account via SEPA, SEPA Instant, Faster Payments or BISERA; settlement split may also be configured.	Capacity is derived dynamically from acquiring activity.
Manual top-ups	Required when the dedicated balance is depleted.	Not required because there is no dedicated OCT top-up flow.
`balance` field	Required; identifies the dedicated OCT funding account.	Not required.
Payout capacity	Limited to funds available in the dedicated OCT account.	Determined dynamically from acquiring inflows and OCT outflows.
OCT Settlement Split	May redirect a configured percentage of acquiring settlement into the dedicated OCT account.	Not applicable.
P2P / A2A	May be supported depending on the merchant setup.	Not supported.
Overdraft / credit line	Not available as part of the standard dedicated-balance flow.	May be available per merchant, subject to approval.

Payout continuity

Dependent on the dedicated account balance.

Dependent on available dynamic capacity and any approved limit.

Supported and Restricted Use Cases

The dynamic balance model supports a subset of OCT use cases.

Code	Use case	Details	Support status
F	Funds disbursement	Loans, insurance payouts, salary advances and refunds.	SUPPORTED
G	Gaming and gambling payouts	Winnings or balance withdrawals from licensed gambling operators.	SUPPORTED
C	Cryptocurrency-related payouts	Fiat payout from a regulated crypto provider after liquidation, where permitted.	SUPPORTED
W	Wallet-related payouts	Payouts to digital or mobile wallets linked to a Visa card.	SUPPORTED
P	Person-to-person transfers	Card-to-card transfers between different individuals.	NOT SUPPORTED
A	Account-to-account transfers	Transfers between accounts belonging to the same person.	NOT SUPPORTED

Restriction: P2P and A2A OCT use cases are not supported under the dynamic balance model.

API Differences Compared with the Existing OCT Setup

The endpoint remains unchanged, but one important funding-related field difference applies.

POST /v1/oct

Field	Pre-Funded Model	Dynamic Balance Model
`balance`	Required; UUID/token identifying the dedicated OCT funding account.	Not required. The available payout capacity is determined automatically. Omit this field.
`amount`	Required.	Required.
`currency`	Required; for example EUR, GBP, USD or BGN.	Required; for example EUR, GBP, USD or BGN.
`merchant`	Required; merchant token.	Required; merchant token.
Card details	Required: either a card token or PAN plus expiry and cardholder name.	Required: either a card token or PAN plus expiry and cardholder name.
`first_name`	Required recipient first name.	Required recipient first name.
`last_name`	Required recipient last name.	Required recipient last name.
`birthday`	Required recipient birthday in ISO 8601 format.	Required recipient birthday in ISO 8601 format.
`nationality`	Required; ISO 3166 alpha-2 country code.	Required; ISO 3166 alpha-2 country code.
`reference`	Required unique transaction reference.	Required unique transaction reference.
`industry_specific_transaction`	Required; supported values depend on the existing OCT setup.	Required; use only F, G, C or W. P2P (P) and A2A (A) are not supported.
`terminal`	Required terminal ID.	Required terminal ID.

Key integration point: if your existing integration sends a balance value for OCTs, that field should be omitted for merchants enabled

on the dynamic balance model.

Response Structure

The response structure remains aligned with the existing OCT implementation.

Field	Description
`code`	Result of the operation; `0` indicates success.
`data.card_number`	PAN of the recipient card.
`data.amount`	Amount of the OCT.
`data.stan`	System trace audit number.
`data.auth_code`	Authorisation code.
`data.currency`	Currency of the OCT.
`data.transaction`	Transaction identifier.
`data.card`	Internal card token, reusable for future payouts where applicable.

Credit Line / Overdraft Considerations

For approved merchants, payout capacity under the dynamic balance model may be extended through a separately agreed overdraft or credit line. This allows OCT payouts to continue when the real-time net balance temporarily falls below zero, up to the approved limit.

The arrangement is subject to Paynetics Risk and commercial approval.
If the overdraft limit is reached, additional OCTs are automatically blocked.
Negative balances are recovered through future acquiring inflows and the agreed settlement model.
The overdraft cannot be reused until the previous negative balance is fully covered.

Commercial note:
availability of a credit line or overdraft is not automatic and depends on a separate approval process.

Settlement Split

The OCT Settlement Split concept used with dedicated OCT balances does not apply to the dynamic balance model.

There is no separate OCT balance to fund through settlement allocation.
Partners do not need to configure a dedicated OCT funding split for this model.

Operational Considerations for Partners

OCT payout capacity is driven by acquiring volume; higher acquiring activity generally provides greater throughput capacity.
Partners should ensure acquiring volumes are sufficient for expected OCT payout activity.
Expected peaks, weekends, promotional campaigns or seasonal increases should be discussed in advance where payout volumes may exceed acquiring inflows.
Where relevant, partners should consider capacity-related declines in operational monitoring and retry logic.

Funding Responsibility

Under the dynamic balance model, merchants do not manually fund a separate OCT account. Instead, payout capacity is driven by acquiring activity and any approved overdraft or credit line.

Merchants remain responsible for ensuring their acquiring volumes support expected OCT payout activity.
If available capacity becomes insufficient and no approved overdraft is configured, OCT transactions will be declined until capacity is restored.
Merchants should contact their Paynetics relationship manager if expected OCT volume is likely to exceed normal acquiring inflows.

Eligibility

To be enabled on the dynamic balance model, a merchant must have an active acquiring setup, be approved for one or more supported OCT use cases, and pass the applicable underwriting and risk review. An overdraft or credit line, if requested, requires separate approval.

An active acquiring relationship with Paynetics is expected.
Supported use cases must be approved as part of merchant onboarding or change management.
P2P and A2A scenarios are excluded from this model.

Merchants currently using the pre-funded OCT model may be migrated following review and approval.

Summary

The dynamic balance model simplifies OCT operations by removing the need for a dedicated pre-funded OCT balance while keeping the existing OCT integration largely unchanged.

No dedicated OCT balance is required.
The balance field is not required.
Settlement split is not applicable.
P2P and A2A are not supported.
Supported use cases remain subject to merchant approval and configuration.

Recommended partner action: review your current OCT request payload and remove the balance field for merchants enabled on the dynamic balance model.

OCT with dynamic acquiring balance model