Deliverability and non-deliverable instruments

• Deliverable: cash in the currency can be transferred out of the country.
• Non-deliverable (ND): export is restricted by government policy; the currency trades onshore but cannot be delivered internationally.
• Deliverability drives: physical vs cash settlement of forwards/options, the settlement currency used for ND instruments, and whether funding/cash balances are permitted in that currency at all.

• Settlement is in a deliverable currency (usually USD or EUR), not the ND currency itself.
• A fixing date precedes the delivery date by enough time to book and settle the fixing trade.
• On the fixing date, a deliverable fixing forward is generated so the non-deliverable amount nets to zero by the delivery date.
• Constraints the system must enforce: never hold a cash balance in an ND currency; the fixing date must respect the holiday calendars of both the fixing source and the settlement currency (see FX spot date and settlement); and reporting must distinguish fixed, not-yet-fixed, and unfixed positions.

• The premium is normally paid in the deliverable currency.
• If both currencies are non-deliverable (unusual), even the premium needs an NDF to convert it to a deliverable currency via an internal counterparty.

• Some currencies are deliverable onshore but non-deliverable offshore, creating two markets with different rates. Canonical example: the Korean Won (KRW) — deliverable within Korea, non-deliverable internationally.
• The Chinese Renminbi has three distinct forms, each with its own rate and rate structure:
  • CNY onshore: mainland China, regulated by the PBoC; CNY rate derived from the Shanghai Interbank Offered Rate, USD rate derived onshore.
  • CNY offshore (ND): the NDF market outside China; USD LIBOR, CNY derived from USD/CNY forwards.
  • CNH: Chinese Yuan offshore deliverable in Hong Kong; USD LIBOR, CNY derived from USD/CNH forwards; its own rate structure.

When an EM currency has onshore and offshore forms that carry different market data (spot, vol surfaces, curves), a single ISO code cannot represent both. The system assigns a pseudo currency code instead:

• Constructed from the country code plus a numeric suffix (e.g. KRW → KR1, KR2).
• Not an ISO 4217 code — it cannot reach settlement directly; used only for market-data association (NDFs, vol surfaces).

Consequences that must stay visible downstream:

1. No independent data: IPV cannot source consensus data for a fake code; Finance must be told explicitly that valuations using it rely on "unclean" market data.
2. No published spot: a proxy must be configured (e.g. the real KRW spot for KR1, plus a spread).
3. P&L attribution: pseudo codes must be tracked separately from real codes to avoid contaminating P&L.
4. Visibility: trades valued with pseudo-code market data should be highlighted in relevant reports.

Deliverability is not only a currency-level property; it also determines how a given deal is settled once booked. Where a currency pair nets two amounts and one side is non-deliverable, the deal is deliverable by convention: the two legs net down to a single amount in the deliverable currency, leaving nothing to settle in the non-deliverable one. Where a currency is genuinely both deliverable, onshore, and non-deliverable, offshore, the convention that marks a particular deal as the deliverable kind is a blank fixing date — the same fixing date that, when present, identifies an NDF or NDO (see above). Deliverability is therefore encoded directly in the deal's own fields, not inferred from the currency alone.

Because the split between an onshore and an offshore market is a jurisdictional one, it constrains not only which curve or spot rate applies but also who may transact and where a trade may be booked. An onshore entity — a genuine local trading presence rather than a nominal one — trades only with counterparties within the same country, including internally: the back-to-back risk-routing mechanism otherwise available to a foreign office without a proper local trading presence is precisely what a genuine onshore entity cannot use to move its risk elsewhere, since doing so would defeat the jurisdictional restriction the split exists to enforce. At the book level, the same restriction rules out an onshore book holding both the deliverable and non-deliverable sides of one currency (a KRW trade alongside a KR1 trade, say) at once, since the two require different regulatory treatment. See Book and the ledger for the entity/business-unit hierarchy this eligibility is ultimately derived from.

A pseudo currency code is legitimate everywhere upstream of settlement — booking, market data, Greeks — precisely because those layers need to distinguish an onshore market from its offshore counterpart. The general ledger and settlement systems are the point past which that distinction must disappear: every profit-and-loss and present-value figure crossing into the ledger is expressed in the underlying ISO currency, never in the pseudo code that produced it. Maintaining this boundary depends on two things happening correctly upstream: the deal itself must already carry its onshore/offshore classification through booking eligibility, and the market data used to value it must be correctly tagged onshore or offshore, so that Greeks and any bump-and-reset revaluation are computed against the right market before the pseudo code's job is done and the figure crosses into the ledger.

A deal whose counterparty is domiciled offshore carries a reporting obligation distinct from ordinary onshore activity, captured in a dedicated Offshore Forward Report. This report is a consequence of the same jurisdictional split underlying everything else in this document: a regulator's interest in offshore activity in a given currency is a separate concern from its interest in that currency's domestic market, and the report exists to keep the two visible independently.