The data model

ISO 20022

The Silora model is ISO 20022 throughout. Two content types carry it: a flattened Simple profile that most integrations use, and the full pain.001 JSON binding for institutions that already speak ISO. There is no XML endpoint.

Why ISO 20022

It is what the networks on the other side of Silora already speak. A proprietary model would have to be translated at every hop, and every translation is a place to lose a field.
Structured party and address data is becoming mandatory under CBPR+. A model that only has addressLine cannot express what regulators now require.
Reason codes are an external, versioned ISO code set. Silora validates against the quarterly set rather than a hardcoded enum, so a new code does not require a Silora release.
Remittance information survives end to end, which is what makes beneficiary-side reconciliation work.

The two content types

Content type	What it is	Use it when
`application/vnd.silora.simple+json`	A flattened projection of the ISO model with a published 1:1 field map. Every example in these docs uses it.	Almost always. It is shorter, obvious to read, and loses nothing.
`application/json`	The full ISO 20022 `pain.001` CustomerCreditTransferInitiation, JSON binding.	You already generate `pain.001` and would rather not flatten it.

The field map

Simple	ISO 20022	Notes
`endToEndId`	`PmtId/EndToEndId`	Your reference. Echoed everywhere, never a path key.
`uetr`	`PmtId/UETR`	Minted by Silora on acceptance. The identity of the payment.
`instructedAmount`	`Amt/InstdAmt`	Amount and currency. Value is a string.
`debtor`	`Dbtr`	Party: name, address, identification.
`debtorAccount`	`DbtrAcct`
`creditor`	`Cdtr`
`creditorAccount`	`CdtrAcct`
`creditorAgent`	`CdtrAgt`	BIC, or clearing system member id such as an IFSC code.
`ultimateDebtor`	`UltmtDbtr`	The party on whose behalf the payment is made.
`purpose`	`Purp/Cd` or `Purp/Prtry`	Local regulatory codes come from a corridor code list.
`categoryPurpose`	`CtgyPurp/Cd`
`charges.bearer`	`ChrgBr`	`DEBT` · `CRED` · `SHAR` · `SLEV`
`remittanceInformation`	`RmtInf`	Both `unstructured` and `structured` are arrays.
`regulatoryReporting`	`RgltryRptg`	FEMA, RBI purpose reporting, and equivalents.
`instructionsForCreditorAgent`	`InstrForCdtrAgt`

Side by side

{
  "endToEndId": "INV-2026-4471",
  "instructedAmount": { "currency": "USD", "value": "24500.00" },
  "creditor": {
    "type": "ORGA",
    "name": "Meridian Textiles Pvt Ltd",
    "address": {
      "streetName": "Trade Centre", "buildingNumber": "402",
      "postCode": "400051", "townName": "Mumbai", "country": "IN"
    }
  },
  "creditorAccount": { "scheme": "IN_ACCOUNT", "id": "50100234567890", "currency": "INR" },
  "creditorAgent": { "clearingSystem": "INIFSC", "clearingSystemMemberId": "HDFC0000123" },
  "purpose": "P0103"
}

Conventions that follow from the model

Amounts are strings, never JSON numbers. "value": "24500.00". IEEE-754 doubles silently corrupt money.
Dates are YYYY-MM-DD; timestamps are RFC 3339 in UTC.
Repeating elements are always arrays, even at length one. remittanceInformation.unstructured is an array of one string far more often than not.
Codes are ISO external code values in caps, validated against the quarterly code set.
Send structured addresses, not address lines. CBPR+ is moving to structured-mandatory and several corridors already reject addressLine with RR03.

Status, mapped both ways

Every payment carries a Silora status and an isoStatus. The Silora status is what you show a human; the ISO status is what reconciles against the network.

Silora `status`	`isoStatus`	Terminal
`INITIATED`	`RCVD`	no
`SCREENED`	`ACTC`	no
`ROUTED`	`ACTC`	no
`SUBMITTED`	`ACSP`	no
`SETTLED`	`ACSC`	yes
`FAILED`	`RJCT`	yes
`CANCELLED`	`CANC`	yes
`RETURNED`	`RJCT` with a `pacs.004` return	yes

Messages behind the scenes

Message	Where it appears
`pain.001`	Your instruction. `POST /payments`, full ISO body.
`pacs.008`	The interbank transfer Silora instructs on your behalf.
`pacs.002`	Status report from the network. Becomes `isoStatus` on the payment.
`pacs.004`	Payment return. Becomes a `payment.returned` webhook.
`camt.056`	Cancellation request, when you cancel after submission.
`camt.053` / `camt.054`	Statement and advice data behind `GET /ledger/accounts`.

You never send or parse these. They are named here so that when a provider or a correspondent mentions one, you know where it sits in the flow.