Skip to content
Last updated

VAS Transaction Flows

The Virtual Account Service (VAS) supports several types of transactions, each designed for specific business purposes. These transactions define how funds move between Sub Accounts, Parent Accounts, the Settlement Account, and ultimately external counterparties.


Overview of Transaction Types

  • Authorized Customer Debit Transactions
    Corporate Clients can initiate a debit from a Customer’s Sub Account (with proper authorization). Funds move up the hierarchy — from Sub → Parent → Settlement — before being transferred externally.

  • Authorized Customer Credit Transactions
    Corporate Clients can credit a Customer’s Sub Account. Funds move down the hierarchy — from Settlement → Parent → Sub — usually representing inbound funding.

  • Deposit and Withdrawal Operations
    These handle customer funds entering or exiting the VAS environment. All deposits and withdrawals are subject to validation, monitoring, and audit.

  • Settlement Processes
    These finalize payments with external counterparties. The Settlement Account is always the source for outbound flows and the recipient of inbound funds.


Transaction Codes and Flows

The following codes define the types of transactions supported within VAS:

TransactionDirectionUse Case
ACRT – Authorized Credit TransferSettlement → Parent → SubFunding virtual accounts (customer credits)
ADBT – Authorized Debit TransferSub → Parent → SettlementConsolidating funds (customer debits)
OTWT – Withdrawal TransferSub → ExternalWithdrawals to customer’s same-name external accounts
OTST – Settlement TransferSettlement → ExternalExternal payments on behalf of customer
REVERSAL – ReversalReject inboundReject unauthorized or invalid inbound funds

Transaction Flows Explained

Deposits (External → Sub Account)

  • A Customer initiates a transfer from an external bank account to a specific Sub Account IBAN.
  • Only pre-approved, registered external IBANs will be accepted.
  • If the source account matches, funds are credited to the Sub Account and made available.
  • If the source account does not match, the funds are held for BCB investigation.

Authorized Customer Debit Transactions (Sub → Settlement)

  • Corporate Client initiates a request to debit a Sub Account and credit the Settlement Account.
  • Flow:
    1. Debit from Sub Account → credit to Parent Account.
    2. Immediate transfer from Parent Account → Settlement Account.
  • If the Sub Account has insufficient funds, the transfer is rejected, and the Corporate Client receives a notification.

Authorized Customer Credit Transactions (Settlement → Sub)

  • Corporate Client initiates a request to debit the Settlement Account and credit a Sub Account.
  • Flow:
    1. Debit from Settlement Account → credit to Parent Account.
    2. Transfer from Parent Account → Sub Account.
  • If the Settlement Account has insufficient funds, the transfer is rejected, and the Corporate Client is notified.

Withdrawals (Sub → External)

  • A Customer requests a withdrawal via the Corporate Client.
  • The Corporate Client initiates a transfer request to BCB.
  • Funds flow: Sub Account → Customer’s designated external account (within BCB or another bank).
  • If the Sub Account has insufficient funds, the transaction is rejected, and the Corporate Client is informed of the reason.

Settlement Transfers (Settlement → External Counterparty)

  • Corporate Client initiates an outbound payment from the Settlement Account.
  • Funds flow: Settlement Account → Counterparty’s account (internal or external).
  • If the Settlement Account has insufficient funds, the transfer is rejected, and the Corporate Client is notified.

Developer Notes

  • Validation: Every transaction is subject to balance checks and authorization controls.
  • Routing: All flows must follow the hierarchy — Sub ↔ Parent ↔ Settlement.
  • Reversals: Unauthorized inbound transactions (e.g., incorrect source IBAN) will be flagged and held pending manual review.
  • Audit Trails: All transfers are fully logged with timestamps, transaction codes, and status updates for reconciliation.
  • Notifications: Clients receive structured error responses when transactions are rejected (e.g., insufficient funds, invalid IBAN).