Card issuing with your own ledger

Treezor supports card issuing models for organizations at different stages of regulatory and card scheme membership. Depending on your setup, Treezor can act as BIN Sponsor and processor, or as processor only when you are a Principal Member and issue cards under your own BIN.

When you manage customer balances in your own ledger, your platform remains the source of truth for balances and the customer experience. Treezor provides card life cycle management, transaction processing, authorization controls, 3D Secure authentication, and transaction data.

Choose your card issuing model

Your regulatory status and card scheme membership determine your issuing model. Separately, your Card Program defines where customer balances are held and how transactions are authorized, processed, and reported.

Criterion	BIN Sponsorship	Affiliate Member	Pure Processing
Your status	Non-regulated organization	Regulated Payment Institution or Electronic Money Institution that is not a Principal Member	Regulated Principal Member
Treezor role	BIN Sponsor and processor	BIN Sponsor; processor when selected	Processor only
Legal issuer and BIN	Treezor, under a Treezor BIN	You, under a Treezor-sponsored BIN	You, under your own BIN
Scheme settlement	Treezor	Treezor	You, directly with the scheme

The regulatory perimeter also changes with the model.

Responsibility	BIN Sponsorship	Affiliate Member	Pure Processing
KYC and AML	Treezor	You, under your license and within Treezor's sponsor governance	You
Safeguarding customer funds	Treezor	You for funds held outside Treezor; Treezor for funds held in Treezor Wallets	You
Scheme compliance and reporting	Treezor	Shared under the program agreement	You
Scheme disputes and chargeback ownership	Treezor	Shared under the program agreement	You
Card processing and authorization switch	Treezor	Treezor, when selected as processor	Treezor

In the Affiliate Member model, compliance responsibilities are shared. The Card Program operating agreement defines the exact allocation. More generally, the program agreement assigns responsibilities for cardholder verification, fraud operations, disputes, reporting, and scheme settlement; these responsibilities cannot be inferred from ledger ownership alone.

Understand availability and setup

The following capabilities are available under the conditions shown.

Capability	Availability and conditions
Client-managed balances and External Authorization	Available as a configured setup. Treezor configures your endpoint, authentication, timeout, and the Master Wallet used for compensation.
Card APIs and transaction webhooks	Available according to the features and options enabled for your Card Program.
Multi-Criteria Dynamic Card (MDC)	Available after feature activation. The applicable authorization-control setup is defined with Treezor.
Mastercard Stand-In Processing (STIP)	Available under rules configured with Mastercard for the BIN range and Card Program.
3D Secure and Risk-Based Authentication (RBA)	Available as a Card Program configuration. If you own the BIN, 3D Secure routing to Treezor's Access Control Server and the corresponding contractual setup must be agreed with Treezor and the card scheme.

Program setup and integration work

Treezor configures the Card Program, External Authorization endpoint and timeout, MDC activation, fraud controls, authentication methods, stand-in processing, and report delivery according to your agreement.

Depending on your setup, Treezor can provide dedicated IT infrastructure. The infrastructure scope and level of isolation are defined during implementation.

If you own the BIN, you coordinate BIN and ICA routing and 3D Secure routing with the card scheme and Treezor. If you are moving an existing Card Program, Treezor has certified processes for migrating BIN and ICA ranges and outstanding balances from a previous processor.

Configuration – Scope of the technical sections

Unless specified otherwise, the following sections describe a client-managed balance setup in which Treezor is the card processor. Feature availability and responsibilities depend on your issuing model and Card Program.

Create the required Treezor objects

Treezor still requires User, Wallet, and Card objects when your customer ledger remains outside Treezor. Complete the company legal-entity User and KYB setup before configuring the Wallet; cardholder Users are then associated with Cards.

Object	Role in the setup
User	The company legal-entity User owns the Master Wallet, while each cardholder User identifies a cardholder. See the Users introduction article and Company creation article.
Master Wallet	Card transaction compensations are posted to one Master Wallet configured for your setup. Master Wallets are available only to eligible projects under their agreement with Treezor. See the Wallet types article.
Card	Represents the physical or virtual payment card. In this setup, Card creation requires the cardholder's userId and the Master Wallet's walletId. See the Cards introduction article.

In this client-managed balance setup, the Treezor objects are linked as follows.

Information – The Master Wallet is not your customer ledger

Card transaction settlements are posted to the Master Wallet. It does not hold individual cardholder balances and is not the scheme settlement account.

Follow a card payment through the program

The card scheme routes authorization and clearing messages for the BIN to Treezor when Treezor is the processor. Treezor evaluates the Card and its configured controls. When External Authorization is enabled, Treezor also calls your authorization service so you can check your ledger and apply your business rules.

After an authorization, Treezor sends card transaction events with the outcome. Treezor does not block cardholder funds when an authorization is accepted in the client-managed balance setup.

Clearing arrives later and provides the final card transaction data. Treezor processes that data and posts the corresponding compensation to the Master Wallet. Scheme settlement is a separate money movement between the card scheme and the scheme settlement account.

Solid arrows show message and data flows. Dotted arrows show Wallet postings and money movements.

Depending on your issuing model, the scheme settlement account belongs to Treezor or to your institution. The exact settlement routes are defined during Card Program setup.

Apply authorization controls

Treezor provides 2 approaches for applying custom authorization controls: External Authorization and MDC. The applicable setup is defined with Treezor as part of your Card Program.

External Authorization

The External Authorization article describes how Treezor sends authorization requests to an endpoint you operate. Your service checks your ledger and business rules, then returns an approval or decline. If you approve the request, Treezor applies the controls configured for the Card before returning the final decision through the scheme.

The default response timeout is 1 second. Treezor can configure a longer timeout on demand. If your service does not answer within the configured timeout, the authorization is declined by default.

External Authorization sequence

The following sequence shows the documented default behavior when External Authorization is configured with client-managed balances. With another authorization-control setup, Treezor does not call your authorization service.

The resulting event includes the same requestId as the External Authorization request. Use it to match the request with the final authorization outcome. Related messages later in the payment life cycle use the same paymentId.

Multi-Criteria Dynamic Card

The MDC article describes how assigned rulesets are evaluated within Treezor. MDC uses transaction attributes and cumulative amounts and counts computed by Treezor. It can enforce spending caps, merchant-category and merchant-list rules, dynamic Wallet selection, and per-ruleset virtual balances, but it cannot read a balance that exists only in your ledger. The feature requires activation.

Card limits and country, merchant, and merchant-category restrictions are described in the Restrictions and limits article. The controls available to a Card depend on its Card Program.

Maintain authorization availability with Mastercard STIP

Within the scope configured for a Card Program, Mastercard Stand-In Processing (STIP) is designed to maintain 100% authorization-service availability for eligible card-present and card-not-present transactions when the processor cannot be reached, such as during an outage or maintenance window. Availability does not guarantee approval: Mastercard approves or declines within the configured stand-in limits, and a limit can be set to 0 for a category or transaction type.

The configuration can distinguish merchant categories, card presence, Card type, transaction count, cumulative amount, and consecutive stand-in days.

The party responsible for the BIN and scheme relationship configures the stand-in rules with Mastercard. When Treezor is your BIN Sponsor, Treezor configures them at your request. If you own the BIN, you agree the rules with Mastercard and Treezor aligns its processing accordingly.

Information – STIP and endpoint timeouts use separate configurations

By default, an External Authorization endpoint timeout results in a decline. Mastercard stand-in applies under the scheme rules configured for your Card Program.

Authenticate online payments and manage card risk

Use 3D Secure Risk-Based Authentication

For eligible online payments, Treezor's Access Control Server performs a real-time risk assessment and returns a frictionless, challenge, or reject outcome. For SCA-compliant card authentication, Out-of-Band authentication through your application is the primary enrollment method, and SMS one-time password can be enrolled as a fallback.

Treezor manages the Access Control Server integration and authentication-method enrollment. Risk rules, enabled methods, fallback behavior, branding, and languages are configured for the Card Program and BIN range.

RBA assesses risk during 3D Secure authentication; it does not replace the card authorization controls. The SCA for card transactions article describes the enrollment and authentication flow.

Monitor card fraud

Card authorization requests are screened by Treezor's fraud monitoring system, which combines standard rules—including velocity, limits, sensitive merchant categories, countries, and transaction types—with custom rules built for your program.

Treezor's Fraud team analyzes the alerts generated. A relevant alert is escalated to you for confirmation with the cardholder. Feedback on confirmed fraud and legitimate activity helps improve rule accuracy.

Operational actions after confirmed fraud—including blocking and replacing the Card, sending a dispute kit, and chargeback handling—are allocated in the Card Program operating agreement and depend on your issuing model. Treezor's expert team supports the broader chargeback analysis according to that agreement.

These controls have different scopes: RBA assesses 3D Secure authentication, Treezor's fraud tool monitors card authorization activity, MDC and Card restrictions enforce configured controls, and External Authorization lets you apply your own logic.

Distinguish clearing from scheme settlement

Treezor uses settlement for the card transaction step that carries the final amount and produces the corresponding Wallet posting (paymentStatus: S). Clearing is the scheme-level exchange of final transaction data that produces it. Scheme settlement is a separate movement of funds between the card scheme and the BIN Sponsor's settlement account.

Treezor manages scheme settlement when it acts as BIN Sponsor. In the Pure Processing model, you settle directly with the scheme. Clearing and scheme settlement timing depends on the scheme and Card Program.

Clearing sequence

The following sequence shows an online authorization followed by transaction settlement when client-managed balances use a Master Wallet. It separates transaction settlement and the Wallet posting from scheme settlement.

The Master Wallet path shown applies to this client-managed balance setup.

A single authorization can result in a partial settlement, multiple settlements, a reversal, or no settlement. A direct settlement has no prior authorization or hold. An offline authorization is reported when clearing arrives with paymentStatus: C.

Reconcile your ledger

Record the events documented in the Card transaction events article in your ledger integration, including relevant cardtransaction.create events. Use their identifiers according to their scope:

• requestId links an External Authorization call to its resulting authorization event.
• paymentId correlates related card transaction messages across the payment life cycle.
• For a settled card transaction, the associated Wallet transaction.create event uses its cardtransactionId as foreignId.

An authorization and its final amount are not always one-to-one. An authorization can be reversed or expire, and settlement can be partial or split across multiple events. Your ledger must:

1. Place a hold after an approved authorization.
2. Adjust or release the hold after settlement or reversal events.
3. Expire unmatched holds according to the timing rules agreed for the program.
4. Post final customer-ledger amounts from settled events.

Treezor does not send a new card transaction webhook solely when an authorization expires. Do not interpret a missing event as a decline. Track unmatched and mismatched items as reconciliation exceptions. The Card transaction life cycle article describes transaction events and statuses.

Match settled card activity to the Master Wallet postings and the BIN Sponsor's settlement statement. This separates customer accounting, Treezor compensation, and scheme cash movements.

Use webhooks and daily reports

Webhooks provide card events as they occur. Treezor can also provide CSV exports for client-managed balance programs. The exact set of extracts, their frequency, freshness, specifications, and secure delivery channel are agreed during Card Program implementation.

Export	Typical frequency and freshness	Purpose
Ledger transaction extract	Daily; a delivery on day D contains D-1 activity	Reconcile Treezor Wallet debit and credit entries, references, amounts, currencies, balances, and value dates
Detailed card transaction extract	Daily; a delivery on day D contains D-2 activity	Reconcile Card and merchant data, scheme dates, amounts, interchange, tokenization, and 3D Secure information
Balance snapshot	Daily; a delivery on day D contains the previous day's position	Snapshot the Wallets in your Treezor environment at midnight on the previous day

In the documented client-managed setup, authorization, authorized-balance, and card-reserve values in the balance snapshot are 0 because Treezor does not hold the cardholder balances.

A SEPA-oriented bank reconciliation extract, when included in your setup, serves a different purpose and is not a card scheme settlement statement.

Use Treezor's card processing capabilities

Treezor's existing card integration provides the processing capabilities used by this setup:

• Create and manage virtual and physical Cards with the Cards introduction article and Card creation article.
• Configure limits, Card options, and country, MCC, and MID restrictions with the Restrictions and limits article.
• Manage PAN, PIN, and CVV operations with the PCI DSS endpoints article.
• Provision supported Cards to Apple Pay, Google Pay, and Samsung Pay with the X-Pay article.
• Consume real-time Card events with the Card transaction events article.

Continue your integration

A typical integration follows this sequence:

1. Define your issuing model, BIN routing, settlement responsibilities, and Card Program with Treezor.
2. Complete the company legal-entity User and KYB setup by following the Company creation article.
3. Work with Treezor to create and configure the Master Wallet used for compensation.
4. Create or synchronize cardholder Users by following the Users introduction article.
5. Create Cards with the relevant userId, walletId, and Card Program by following the Card creation article.
6. Define the applicable authorization-control setup with the External Authorization article and MDC article.
7. Configure 3D Secure authentication, fraud operations, and Mastercard STIP for the Card Program.
8. Consume the events documented in the Card transaction events article and configure the reports required for your Card Program.