Hub
Settlement and clearing: window, statement, ledger
Every session becomes a CDR; every CDR enters a settlement window. When the window closes, the two parties receive one hub-signed netting statement, and after acknowledgement a payment obligation is created. This page explains the states, the parameters the agreement sets, the ledger and where the fee sits.
Window
Window states
One window per partner pair per period. Late CDRs enter during the grace period, disputes surface before anything is signed, close freezes.
- 01 OPEN
The window opens at the period start. Validated CDRs of the partner pair enter as they arrive.
- 02 GRACE_PERIOD
After the period end, late CDRs and corrections still enter until the grace period ends.
- 03 RECONCILING
The partner dispute window. Disputes surface here, before anything is signed; a disputed window closes only after resolution.
- 04 CLOSED
Period boundaries, agreement version and window hash are frozen. A second close is refused.
Statement
Statement states
Derived from the closed window, signed by the hub, acknowledged by both parties. The payment obligation is at the end of the chain, not the beginning.
- 01 GENERATED
Derived from the closed window and the agreement’s netting mode.
- 02 PUBLISHED
Hub-signed. Partners fetch the statement and verify it against the ledger with the hub’s published key.
- 03 ACKNOWLEDGED
Both partners acknowledge, or the acknowledgement timeout passes. Only then can a payment obligation be created.
- 04 PAYMENT OBLIGATION
Debtor, creditor, amount, currency and due date (window close plus the agreement’s payment-due days). Money moves through the rail chosen in the agreement; the hub is not a payment institution.
Inspect evidence
Settlement window state machine· Source code review
The clearing platform moves each settlement window through OPEN, GRACE_PERIOD, RECONCILING and CLOSED; late CDRs enter during the grace period and disputes surface before close.
Supports:That settlement periods, netting statements and payment obligations are produced by the platform.
Does not show:That money has moved between partners through the hub: settlement runs in dry-run until the financial go-live gate closes, and invoicing is fenced until then.
Source: ChargeBridge hub source repository (private), reviewed on the date given · Verified4 October 2026
Hash-chained settlement ledger· Source code review
Ledger entries are chained by hash so a statement can be re-verified against its inputs; hub fees are booked as separate lines for each party and never netted against roaming amounts.
Supports:Tamper-evidence of the ledger and the “hub fee outside netting” rule.
Does not show:Fee rates or splits; those are in the participation agreement, not on this site.
Source: ChargeBridge hub source repository (private), reviewed on the date given · Verified4 October 2026
Settlement architecture: agreements, windows, statements, obligations· Document
Bilateral, versioned agreements define cycle, grace period, dispute window, fee allocation, payment automation and FX policy; windows move OPEN → GRACE_PERIOD → RECONCILING → CLOSED; statements move GENERATED → PUBLISHED → ACKNOWLEDGED and are hub-signed; obligations carry debtor, creditor, amount and due date.
Supports:The structure described on the settlement page.
Does not show:Any rate, amount or that real money has moved; payment automation beyond manual mode is configured per partner after the financial go-live gate.
Source: Hub repository, docs/architecture/settlement (domain model, state machines, cycle computation) · Verified4 October 2026
Agreement
What the agreement sets
Agreements are bilateral and versioned; at most one active agreement per partner pair. The platform reads its parameters from the agreement and adds no decision of its own.
| Term | Options | Note |
|---|---|---|
| Cycle | Daily · every N days · weekly · biweekly · monthly · custom | Anchored to a wall-clock time in the agreement’s time zone (for example 00:00 Europe/Istanbul); daylight-saving days are 23 or 25 hours, amounts are unaffected; month-end dates are clamped. |
| Grace period | Per agreement | Late CDRs and versioned corrections enter after the period end; CDRs arriving after the grace period spill into the next window. |
| Dispute window | Days per agreement; maximum disputes per window; escalation after N | Disputes are raised while the window is reconciling, not after the statement is signed. |
| Fee allocation | Sender · receiver · split between the two parties · absorbed by the hub | The hub fee is booked as its own line for each party and is never netted against roaming amounts. The rate is in the participation agreement, not on this site. |
| Payment automation | Manual · automatic below a cap · fully automatic | The rail (payment provider or open-banking initiation) and the mandate are chosen per partner. Card data never passes through the hub. |
| Currency and FX | Hub-locked rate · provider rate · partner rate; locked at period start, period end or transaction time | Multi-currency pairs produce one net direction per currency. |
Agreement templates and versions on Agreements →
Ledger
Hash-chained, immutable, re-verifiable
Each ledger entry carries the hash of the one before it. A line changed afterwards breaks the chain and becomes visible; scope changes are written to the audit ledger under the same discipline.
Validation against tariff and session, idempotent intake, then entry into the settlement window. Türkiye-specific fields travel in the tr-cdr-additionals extension.
-
Every ledger entry is chained by hash; a statement can be re-verified against its inputs at any time.
Inspect evidence
All evidence records →Hash-chained settlement ledger· Source code review
Ledger entries are chained by hash so a statement can be re-verified against its inputs; hub fees are booked as separate lines for each party and never netted against roaming amounts.
Supports:Tamper-evidence of the ledger and the “hub fee outside netting” rule.
Does not show:Fee rates or splits; those are in the participation agreement, not on this site.
Source: ChargeBridge hub source repository (private), reviewed on the date given · Verified4 October 2026
-
A closed window is immutable. Compensation after a chargeback goes through a new statement in the next window, never by re-opening.
Inspect evidence
Settlement window state machine· Source code review
The clearing platform moves each settlement window through OPEN, GRACE_PERIOD, RECONCILING and CLOSED; late CDRs enter during the grace period and disputes surface before close.
Supports:That settlement periods, netting statements and payment obligations are produced by the platform.
Does not show:That money has moved between partners through the hub: settlement runs in dry-run until the financial go-live gate closes, and invoicing is fenced until then.
Source: ChargeBridge hub source repository (private), reviewed on the date given · Verified4 October 2026
Hash-chained settlement ledger· Source code review
Ledger entries are chained by hash so a statement can be re-verified against its inputs; hub fees are booked as separate lines for each party and never netted against roaming amounts.
Supports:Tamper-evidence of the ledger and the “hub fee outside netting” rule.
Does not show:Fee rates or splits; those are in the participation agreement, not on this site.
Source: ChargeBridge hub source repository (private), reviewed on the date given · Verified4 October 2026
All evidence records →Settlement architecture: agreements, windows, statements, obligations· Document
Bilateral, versioned agreements define cycle, grace period, dispute window, fee allocation, payment automation and FX policy; windows move OPEN → GRACE_PERIOD → RECONCILING → CLOSED; statements move GENERATED → PUBLISHED → ACKNOWLEDGED and are hub-signed; obligations carry debtor, creditor, amount and due date.
Supports:The structure described on the settlement page.
Does not show:Any rate, amount or that real money has moved; payment automation beyond manual mode is configured per partner after the financial go-live gate.
Source: Hub repository, docs/architecture/settlement (domain model, state machines, cycle computation) · Verified4 October 2026
-
Agreements are bilateral and versioned: at most one active agreement per partner pair; amendments form an ordered chain; the version is frozen into each window at close.
Inspect evidence
Settlement window state machine· Source code review
The clearing platform moves each settlement window through OPEN, GRACE_PERIOD, RECONCILING and CLOSED; late CDRs enter during the grace period and disputes surface before close.
Supports:That settlement periods, netting statements and payment obligations are produced by the platform.
Does not show:That money has moved between partners through the hub: settlement runs in dry-run until the financial go-live gate closes, and invoicing is fenced until then.
Source: ChargeBridge hub source repository (private), reviewed on the date given · Verified4 October 2026
Hash-chained settlement ledger· Source code review
Ledger entries are chained by hash so a statement can be re-verified against its inputs; hub fees are booked as separate lines for each party and never netted against roaming amounts.
Supports:Tamper-evidence of the ledger and the “hub fee outside netting” rule.
Does not show:Fee rates or splits; those are in the participation agreement, not on this site.
Source: ChargeBridge hub source repository (private), reviewed on the date given · Verified4 October 2026
All evidence records →Settlement architecture: agreements, windows, statements, obligations· Document
Bilateral, versioned agreements define cycle, grace period, dispute window, fee allocation, payment automation and FX policy; windows move OPEN → GRACE_PERIOD → RECONCILING → CLOSED; statements move GENERATED → PUBLISHED → ACKNOWLEDGED and are hub-signed; obligations carry debtor, creditor, amount and due date.
Supports:The structure described on the settlement page.
Does not show:Any rate, amount or that real money has moved; payment automation beyond manual mode is configured per partner after the financial go-live gate.
Source: Hub repository, docs/architecture/settlement (domain model, state machines, cycle computation) · Verified4 October 2026
-
The hub’s output is a reconciliation summary, not a fiscal document. VAT and e-invoicing are the responsibility of the party that issues the CDR.
Inspect evidence
Settlement window state machine· Source code review
The clearing platform moves each settlement window through OPEN, GRACE_PERIOD, RECONCILING and CLOSED; late CDRs enter during the grace period and disputes surface before close.
Supports:That settlement periods, netting statements and payment obligations are produced by the platform.
Does not show:That money has moved between partners through the hub: settlement runs in dry-run until the financial go-live gate closes, and invoicing is fenced until then.
Source: ChargeBridge hub source repository (private), reviewed on the date given · Verified4 October 2026
Hash-chained settlement ledger· Source code review
Ledger entries are chained by hash so a statement can be re-verified against its inputs; hub fees are booked as separate lines for each party and never netted against roaming amounts.
Supports:Tamper-evidence of the ledger and the “hub fee outside netting” rule.
Does not show:Fee rates or splits; those are in the participation agreement, not on this site.
Source: ChargeBridge hub source repository (private), reviewed on the date given · Verified4 October 2026
All evidence records →Settlement architecture: agreements, windows, statements, obligations· Document
Bilateral, versioned agreements define cycle, grace period, dispute window, fee allocation, payment automation and FX policy; windows move OPEN → GRACE_PERIOD → RECONCILING → CLOSED; statements move GENERATED → PUBLISHED → ACKNOWLEDGED and are hub-signed; obligations carry debtor, creditor, amount and due date.
Supports:The structure described on the settlement page.
Does not show:Any rate, amount or that real money has moved; payment automation beyond manual mode is configured per partner after the financial go-live gate.
Source: Hub repository, docs/architecture/settlement (domain model, state machines, cycle computation) · Verified4 October 2026
- 3 evidence records support this section; each also says what it does not show. Evidence records →
Fee
Fees: structure, not rates
This page explains how the fee is computed and where it sits in the statement. The rate itself is in the participation agreement.
- 01
Percentage per CDR
The hub fee is calculated as a percentage for each CDR; there is no flat amount.
- 02
Split per agreement
Sender, receiver, split between the two parties or absorbed by the hub: the allocation is chosen in the agreement.
- 03
Its own line
The fee is booked as a separate line for each party in the statement; it is not buried in the roaming amount.
- 04
Never netted
What gets netted is only the roaming receivables and payables between the two partners.
- 05
Rate in the agreement
The rate is in the participation agreement and is not published on this site.
Inspect evidence
Hash-chained settlement ledger· Source code review
Ledger entries are chained by hash so a statement can be re-verified against its inputs; hub fees are booked as separate lines for each party and never netted against roaming amounts.
Supports:Tamper-evidence of the ledger and the “hub fee outside netting” rule.
Does not show:Fee rates or splits; those are in the participation agreement, not on this site.
Source: ChargeBridge hub source repository (private), reviewed on the date given · Verified4 October 2026
Financial gate
The financial go-live gate
The technical gate opens the handshake and data flow; the financial gate opens real money. The gate closes when these three conditions are met:
- 01
A data processing agreement with every partner
Signed under KVKK before any personal data flows.
- 02
Regulatory registrations
Registrations to be completed on the hub side.
- 03
The e-invoice rail
The rail from statement to invoice; no invoice is issued until then.
Where the service stands
Technical connectivity is live for onboarding partners: handshake, data flow and settlement statements. Settlement runs in dry-run until the financial go-live gate closes (data processing agreements with every partner, regulatory registrations, e-invoicing). No partner names or counts are published on this site; connected parties are visible to each other through the hub directory.
Frequently asked questions
Is the hub fee part of netting?
No. The hub fee is its own line in the statement for each party and is never netted against roaming amounts. What gets netted is only the roaming receivables and payables between the two partners.
How do I verify a statement?
The statement is hub-signed and ledger entries are chained by hash. In the portal you see the CDRs and ledger lines that make up your statement; it can be recomputed from its inputs, verified with the hub’s published key, and a line changed afterwards breaks the chain.
Does money pass through the hub?
No. The hub is not a payment institution; it produces netting statements and payment obligations. Money moves between the parties through the rail chosen in the agreement; card data never passes through the hub. No invoice is issued before the financial go-live gate closes.
How it proceeds
- 01Apply with your role and versions endpoint
- 02Sign the participation agreement and DPA
- 03Handshake in the sandbox, then accept relationships