Talk to us

The Digital Trade Obligation (DTO™) protocol

Commercial credit that systems can actually read.

Pistac.io turns every payment obligation into one structured record that your ERP, your bank and your financier all understand. Created, acknowledged, evidenced, settled.

Talk to usSee how it works
Obligation DTO-4471On schedule
  1. Created
    14 Aug
  2. Acknowledged
    16 Aug
  3. Instalment 1
    30 Sep
  4. Instalment 2
    31 Oct
  5. Settlement
    30 Nov
One record carries
  • 2Identified parties
  • 7Lifecycle states
  • 3Evidence documents

The problem

Every system holds a piece. None holds the obligation.

A single commercial obligation is spread across a contract, a purchase order, an invoice, a delivery note and a banking instruction. Each records part of the transaction. None carries the obligation itself.

  • Contract

    Sets the terms the obligation arises from, then sits in a drive nobody opens.

  • Purchase order

    Records what was ordered, not what is now owed or when it falls due.

  • Invoice

    Records a claim on one date. It knows nothing about the lifecycle behind it.

  • Delivery note

    Confirms fulfilment, held apart from the payment terms it should trigger.

  • Ledger entry

    Reflects one side of the obligation. The counterparty books a different truth.

  • Bank instruction

    Moves the money and carries none of the context that justified it.

The result is familiar. Reconciliation by email, exposure nobody can total, and financing decisions made on partial information.

The record

One record, from issue to settlement.

A DTO™ is a structured representation of what one business owes another. It carries the parties, the terms, the evidence and the current state in a single object that stays correct as the obligation moves.

What a DTO™ is not

  • Cryptocurrency, a token, or a blockchain asset
  • A digital invoice, or a replacement for one
  • A payment method, a loan, or a form of money

An invoice records a claim. A DTO™ represents the obligation behind it.

Obligation DTO-4471Acknowledged
Obligor
Buyer Ltd
Beneficiary
Supplier AB
Amount
48,000.00 EUR
Maturity
30 Nov 2026
Instalments
2 of 3 outstanding
Evidence
PO, delivery note, acceptance
Jurisdiction
Sweden, governing law on file

The platform

Everything an obligation needs, in one place.

DTO™ is the protocol. Pistac.io is the company building on it, and the platform and network that come with it.

  • Issue and acknowledge

    Create an obligation from an existing order or invoice, send it to the counterparty, and capture their acknowledgement as a signed state change rather than an email thread.

  • Attach the evidence

    Purchase orders, delivery notes, acceptance records and amendments attach to the obligation itself, so the proof travels with the claim instead of sitting in a separate folder.

  • Track the lifecycle

    Amendments, instalment schedules, partial settlement and maturity are held as state. Both sides read the same status at the same moment, with a full history behind it.

  • Connect your systems

    Read and write against the ERP, accounting and treasury platforms already holding the data. The obligation record stays in step without anyone rekeying it.

  • See the exposure

    Query what is owed, by whom, and when it falls due across every obligation connected to you. Concentration and maturity clustering stop being spreadsheet work.

  • Support financing

    Where the contracts and the law allow it, a structured obligation gives a financier something verifiable to lend against, and gives you a cleaner route to working capital.

The network

Connected obligations become a credit graph.

Each obligation is a relationship between two parties. As more of them connect, exposure, concentration and maturity stop being spreadsheet exercises and become something you can query.

Netting

Obligations form chains. A owes B, B owes C, C owes A. When the structure is visible, offsetting positions can be identified and settled once instead of three times, wherever the contracts, the law and the operations of every party involved allow it.

Visibility extends to entities connected to Pistac.io and the permissions they grant. It does not extend to companies that are not.

Counterparty exposureAcross connected counterparties
  • Supplier AB142,400.00
  • Buyer Ltd96,800.00
  • Distributor SA61,250.00
  • Carrier Oy38,000.00
  • Four others32,900.00

Interoperability

Built to connect, not replace.

Nothing here asks you to move off the systems you run. The obligation record sits alongside them and keeps them in agreement.

ERP
Stays your system of record for operations.
Accounting
Stays your system of record for reporting.
Banks
Stay the custodians of funds and the settlement route.
Payment networks
Keep moving money exactly as they do now.
Financiers
Keep providing liquidity, against records they can verify.
Identity
Existing frameworks establish who the parties are.

Where we are

Defined, and now being built.

We would rather be precise about this than impressive.

Defined

  • The DTO™ protocol model
  • The obligation structure
  • The lifecycle framework
  • The legal-profile approach
  • The network architecture

In progress

  • Technical implementation
  • Legal validation
  • Selective industry engagement

Digital structure does not replace legal substance

Pistac.io does not make a claim enforceable. Whether an obligation binds depends on the agreements behind it, the consent and identity of the parties, the evidence, and the law of the jurisdiction it sits in. The architecture is designed to carry that context across common-law, civil-law and Sharia-compatible frameworks rather than to override it.

Pistac.io is not a dispute-resolution service.

Contact

Start a conversation.

We are talking with investors, financial institutions, professional-services firms, technology partners, and legal and regulatory specialists.

Talk to us

contact@pistac.io