The legal basis for tokenized receivables in Switzerland and the EU.

In most cases no. Under FinSA Art. 4, debt instruments (a receivable is a debt instrument) are exempt from prospectus requirements when offered to a closed circle of professional or pre-screened investors. The token we mint is a CMTAT — a permissioned token (ERC-3643-compatible) where transfer requires a compliance check, which keeps the offering inside the exemption. CurioInvest provides the KYC + whitelist tooling and a per-token transfer hook, but the legal opinion is yours: we ship the rails, not the ruling.

The DLT Act creates a new federal register of ledger-based rights. A dematerialised share, a tokenised bond, a non-fungible right — any of these can now be legally registered as a civil-law right in a DLT recognised by FINMA. For tokenised receivables specifically, the bigger effect is upstream: we now have a clean answer to the question "what kind of right does the token represent?" The token represents a digital ledger entry of the underlying claim. The underlying claim is registered (or, in most receivables, not yet) in that ledger. This is the foundation CurioExtract is built on.

ERC-20 is the base token standard. ERC-1404 adds transfer validation with a hook that returns a numeric reason code. ERC-3643 (formerly T-REX) is the full identity-aware regulated security token. CMTAT, developed by the Capital Market and Technology Association (CMTA), is a more modular evolution of those — same compliance hooks, but split across many small, composable modules. The contracts in this dashboard mint CMTATs because they're easier to compose, audited by Wake Arena, and used by UBS / Taurus / Syz in production.

ERC-20 has no transfer validation — anyone with the address can send anywhere. For a regulated receivable, that's disqualifying: you have no way to enforce a whitelist, and a stray transfer to a non-KYC wallet can't be reversed. ERC-3643 (and the modular CMTAT that descends from it) has a built-in `transferred(spender, from, to, value)` hook on every transfer that runs the compliance check, and a `detectTransferRestriction` view function the holder can call before sending. We use the CMTA RuleEngine + a Swiss-DLT-specific rule (jurisdiction whitelist, KYC verification, settlement-freeze) on top of CMTAT v3.0.0.

Postgres for the application state. For tokenized receivables, the CMTAT contract is deployed to Polygon mainnet (or Polygon Amoy for testing). The jurisdiction check, KYC status, and settlement-freeze all live on-chain. Off-chain components — the AI extraction layer, the human approval flow, the dashboard — sit on Swiss-hosted Postgres (currently Neon). Documents stay on CurioExtract for the duration of the receivable, then migrate to a long-term cold store at settlement.

Two paths. Manual: the issuer marks the receivable `settled` via `rule.markSettled(tokenId)`. On-chain: a settlement oracle (e.g., a Polygon Oracles feed reading the obligor's bank API) automatically calls `markSettled` on payment confirmation. In both cases, the token is frozen from further transfers (settlement-freeze), then the issuer `burn()`s it to retire the receivable. Investor capital is returned per the term sheet. T+2 is the design target; actual time depends on how the issuer wires the oracle.

The token representing the receivable lives in the issuer's multisig during tokenization. When an investor subscribes, `transferFrom` moves the token to the investor's wallet, and the investor holds the receivable claim. The CMTAT's `forcedTransfer` and `accountFreeze` are admin-only — and the admin is governed by a 2-of-3 multisig of named CurioInvest officers. Investors can see, in the dashboard, exactly which wallet holds the claim, the exact `transfer` history, and the on-chain block height at every step.

Three failure modes, surfaced in the dashboard: (1) late payment triggers a penalty-interest accrual (12% above the contract APR) and auto-notification; (2) default triggers Swiss SchKG (Betreibungsbegehren) legal recovery, 70-90% expected recovery; (3) bankruptcy triggers the underlying insolvency proceeding, 40-60% expected recovery, 12-18 month timeline. The dashboard's 'Backtest' tool runs the whole 20-contract portfolio through these scenarios so the CFO sees the worst case before issuing.

For issuing tokenized receivables, the issuer can be a CH/EU/DE/AT/IT/FR company. The investor base needs to be a 'qualified investor' or a 'professional client' under FinSA / EU MIFID, with documented KYC. For the demo we use the CurioInvest Swiss-DLT whitelist (CH / DE / AT / IT / FR). If your obligor or investor is in the US or Asia, we need a separate analysis — talk to us. (See the 'Open the SIM' CTA — that's the conversation-starter.)

Yes. The tokenization events are recorded on a public blockchain (Polygon) with immutable block-height references. The application state sits in a Postgres database that you own and can export. The `transferred` and `mint` events are emitted as standard ERC-20 Transfer events and CMTAT-specific events. You can hand the auditor a CSV of every contract + its on-chain transaction history + the rule enforcement log from the `TransferWithData` / `DetectedTransferRestriction` events. That's your audit trail.