One integration. The whole registry.

Issue, hold, transfer, and verify eInstruments over plain HTTPS + JSON. Every response is post-quantum signed (NIST FIPS 204 · ML-DSA-65) and anchored in a hash-chained audit ledger — evidence-grade by design, independently re-verifiable by anyone.

Base URL: https://iset.finance/api

Authentication

Two levels, by design:

Public — no credentials

Verification is public. Anyone holding a record's reference may confirm it — that is the point of a registry.

Session — passkey sign-in

Issuing, listing, and transferring act on your records, so they require your account session. Sign in at /console/ with a passkey, then send the session token:

# the dashboard does this automatically; direct callers send:
Authorization: Bearer <session_token>

The lifecycle

A record moves through controlled states. Every transition is a signed, audit-anchored event; invalid transitions are refused by the registry.

pledge grants a lender control during a credit term · release returns it · transfer passes control to a new holder (MLETR-aligned §10 for transferable records) · discharge ends the instrument — terminal, irreversible.

Compose a request

Configure a record on the left — the exact API request builds itself on the right. Copy it, or sign in to issue it for real.

Verify a record

curl https://iset.finance/api/etr/verify/fvt_9f40e226_87a14068

{
  "ok": true, "verified": true,
  "record": {
    "etr_id": "fvt_9f40e226_87a14068",
    "instrument": "ePN", "instrument_name": "Electronic Promissory Note",
    "amount": "2500000", "currency": "PHP",
    "status": "registered", "holder_ref": "phase2-test",
    "history": [], "sandbox": true,
    "signature": "ML-DSA-65:…", "record_hash": "sha-256:…"
  },
  "brand": null
}

Issue an eInstrument

curl -X POST https://iset.finance/api/etr/issue \
  -H "Authorization: Bearer <session_token>" \
  -H "Content-Type: application/json" \
  -d '{"type":"ePN","amount":"2500000","currency":"PHP","holder_ref":"Juan Dela Cruz"}'

{ "etr_id": "fvt_…", "status": "registered", "signature": "ML-DSA-65:…",
  "court_admissible": true, "verify_path": "/v1/etr/verify/fvt_…" }

List records

{ "ok": true, "count": 2, "records": [ … ] }

Transfer control

curl -X POST https://iset.finance/api/etr/transfer \
  -H "Authorization: Bearer <session_token>" \
  -H "Content-Type: application/json" \
  -d '{"etr_id":"fvt_…","action":"pledge","to_ref":"Partner Bank A"}'

{ "isp_name": "ETR_CONTROL_PLEDGE", "status": "pledged",
  "holder_ref": "Partner Bank A", "signature": "ML-DSA-65:…" }

Subscriber profile

Audit retrieval

Model Context Protocol

An AI client can verify records and read the instrument schemas without an integration. Point any MCP client at the endpoint below — no SDK, no account, no key.

JSON-RPC 2.0. A GET returns the discovery document to a client and a readable page to a browser, so the same URL serves both.

Tools

Connect a client

{
  "mcpServers": {
    "iset-etr": { "url": "https://iset.finance/mcp" }
  }
}

Try it by asking your client to verify EPN-2026-SAMPLE-0001 — or run every call yourself in the sandbox, no signup, with the well-known sandbox key iset_sandbox_demo_v1.

The control layer is chain-portable by design — the registry record is chain-agnostic, and each network gets its own anchoring contract. Stellar is the first supported network.

The registry above is the system of record for terms and identity. A separate, public control layer runs on Stellar (Soroban): the epn_escrow contract governs who holds a note — exclusively, one holder at a time — and its full lifecycle through endorsement, settlement, or default. The contract never custodies or moves funds; it enforces control. The two layers are deliberately decoupled — the registry operates standalone without it (see deployment spectrum).

The reference application is live at stellar.iset.finance — issue, endorse, accept, settle, and verify against real wallets, no account needed.

{ "etr_id": "fvt_…", "record_hash": "sha-256:…",
  "signature": "ML-DSA-65:…", "audit_id": "aud_…", "sandbox": true }

The epn_escrow contract

Rust / Soroban. Every state transition requires the acting party's on-chain authorization and emits an event. Endorsement is a two-signature handshake — offer by the current holder, acceptance by the named endorsee — so transfer of control is bilateral, exclusive, and provable.

Deployments

For institutions — legal posture & integration

Legal posture, stated precisely

Records issued here have legal standing as electronic documents and signatures under the Electronic Commerce Act (RA 8792) — an electronic record is not denied validity for being electronic. What RA 8792 does not settle is full negotiable-instrument status: the electronic equivalent of indorsement and delivery. That is precisely what the UNCITRAL MLETR codifies — and the Philippines has not yet enacted it.

Our position is therefore deliberate: we built the control architecture MLETR's test requires — a single authoritative record of control, exclusive control enforced by contract, integrity by hash-chain and signature, and an identifiable current holder — so records are MLETR-ready ahead of recognition, not claimed compliant before it. For secured lenders, the Personal Property Security Act (RA 11057) is the operative hook today: §19 ranks possession/control of an instrument above registration when perfecting a security interest — and on-chain exclusive control is the electronic analogue of possession.

Deployment spectrum — fiat-first, chain-optional

Records are fiat-denominated (PHP by default), and because the settlement contract never custodies funds, actual payment has always run on a separate rail — which can be InstaPay, PESONet, a bank transfer, or a wallet, with the payment reference entered into the signed audit event. That makes two deployment modes real today, not roadmap:

An institution can start registry-only — zero blockchain touch — and enable anchoring later without re-architecture, because the layers were never coupled. One honest caveat: in registry-only mode, the RA 11057 §19 control-as-possession argument is softer — control enforced by an operator's server is a weaker form of "possession" than contract-enforced control. We state that before counsel asks.

Integration paths

Download the institutional brief → — a one-page summary built for internal circulation: what this is, proof of deployment, legal posture, pilot shape, and known limits.

Contact: trust@iset.finance

Errors