Currencies

The chapter advances the argument that managing a currency well means understanding what a currency actually is, its identity, the extensions that make it usable, the interface that governs its lifecycle, and the programmatic equivalents — and it proceeds in that order. It begins with the conceptual foundation in Money, currency, and cash, distinguishing three terms routinely conflated in casual usage; this framing is what makes the rest of the chapter's choices legible, not just a list of fields. It then turns to a currency's own birth-to-retirement Currency lifecycle, background the chapter draws on without OreStudio exposing it as a field. From there it establishes identity in ISO 4217 and its limitations, which sets out the codes that name a currency and the gaps that motivate ORE Studio's extensions. It then surveys the body of records in The Currencies window before narrowing to a single record in Currency Details and its General, Formatting, Rounding, and Provenance tabs. It then turns to changing a record under audit — Editing and Currency history — culminating in reverting to an earlier version, the point at which the bitemporal audit trail does its work. It then documents the auxiliary classification tables — rounding types, market tiers, and monetary natures — whose values a currency references, and finally shows the same operations automated from the shell and the CLI. The Conclusion draws these steps together.

Money, currency, and cash are used almost interchangeably in everyday speech, yet they name three distinct, if related, concepts, each nested within the one before it. Disentangling them clarifies what ORE Studio's Currency record is actually modelling, and, just as importantly, what it deliberately is not.

Money is the broadest of the three terms: any item or verifiable record generally accepted as payment for goods and services, or as repayment of debts, within a particular society. It is best understood not as a physical thing but as a social convention, one that functions precisely because a sufficiently large group of people believes it functions, and which ceases to function the moment that belief collapses. What qualifies as money is best captured by what it does rather than what it is: it serves as a medium of exchange, offering an efficient alternative to barter; as a unit of account, letting value be expressed numerically and compared across otherwise incommensurable goods; as a store of value, preserving purchasing power across time; and as a standard of deferred payment, so that an amount agreed today retains roughly the same value when it falls due in the future. Anything fulfilling these functions counts as money, which is why money has, historically, taken several distinct forms. Commodity money derives its value from the scarcity and physical usefulness of the substance embodying it, gold and silver being the paradigm cases. Fiat money, by contrast, carries no intrinsic value of its own; it is money purely because a government or a mutual agreement between parties declares it so. Bank money is more abstract still, consisting entirely of records: it is created the moment a bank extends a loan by crediting the borrower's deposit account, and destroyed the moment that loan is repaid. Despite the popular association of "money" with notes and coins, bank money constitutes the overwhelming majority of the money supply in any modern economy, physical cash typically accounting for a small single-digit percentage of the total. Cryptocurrencies form a fourth, more recent and non-standard category: digital assets used as a medium of exchange, with ownership recorded cryptographically and, typically, no central issuing authority standing behind them.

Currency narrows money down to a system of money in common use within a defined area of circulation, usually a country or a group of countries sharing a monetary union. Two meanings coexist in ordinary usage, the physical representation of banknotes and coins on one hand, and the abstract system of money itself on the other, the latter being the more useful framing for a system such as ORE Studio, given how small a fraction of any modern money supply physical cash actually represents. Being standardised by ISO 4217 is not a precondition for counting as a currency in this conceptual sense; standardisation is better understood as a seal of approval than as a definition. The currencies of smaller nations not covered by the standard, and cryptocurrencies, which rely on informal, community-driven symbols such as BTC or XBT for Bitcoin rather than an assigned ISO code, are no less currencies for lacking one. A currency also has a lifecycle of its own, distinct from the lifecycle of any individual note or coin — see Currency lifecycle below.

Cash narrows the concept furthest of the three. It is money in the physical form of banknotes and coins, or, in the bookkeeping sense more relevant to a system like ORE Studio, the broader class of current assets comprising currency or currency-equivalents that can be accessed immediately or near-immediately. A bank deposit falls under this broader definition: it is a financial asset rather than physical currency, yet liquid enough to count as cash for most practical purposes. The relationship between the three terms can be summarised as a chain of increasingly narrow specialisation: not all money is a currency in the systemic sense, since commodity money and cryptocurrencies stretch the definition in different directions; and not all currency holdings are cash, since a currency can equally be held in a comparatively illiquid financial-asset form.

ORE Studio's Currency reference-data record, the subject of the remainder of this chapter, models currency in precisely this narrower, systemic sense: a named, identified system of money, equipped with the extensions described in the next section that let ORE Studio put it to practical use in calculations. The chapter does not attempt to model money in the abstract, nor the accounting concept of cash; those notions are drawn upon, where relevant, by the trading and booking chapters that build upon the currency reference data documented here.

A currency is born when created and put into circulation, lives while in general use, and dies when eventually withdrawn — whether replaced by a successor currency, absorbed into a monetary union, or simply discontinued — though records of transactions conducted during its life must still be retained long after that withdrawal. This is background the rest of the chapter builds on, not a field OreStudio exposes directly: unlike a book, a currency record carries no status column of its own; a withdrawn currency simply stops being referenced in new records; its history remains intact under the same bitemporal audit trail as any other change.

The same birth-life-death shape recurs at three nested levels: the currency itself, its individual denominations (a given note or coin value can be introduced or discontinued independently of the currency surviving), and individual physical instances. Recognising the pattern as fractal is what keeps "currency lifecycle" from being mistaken for a single, currency-wide, all-or-nothing event.

Redenominations, currency replacements, and monetary unions forming or dissolving occur more often than a system designer might expect, and rarely afford the luxury of careful advance planning; a system not built to anticipate such events — positions, reference data, and historical records all still keyed to a code that has just been withdrawn or redefined — can find itself significantly disrupted when one eventually occurs.

The international standard for currency codes is ISO 4217. It defines a three-letter alphabetic code (USD, EUR, GBP), a three-digit numeric code (840, 978, 826), a currency name, and the number of decimal places — for example, USD has 2 minor units, meaning amounts are expressed to the nearest cent.

ISO 4217 is widely adopted and ORE Studio uses it as its primary identifier. However, the standard has gaps that matter in practice:

• It does not classify currencies by market tier — the distinction between major G10 currencies and emerging-market currencies is economically important but absent from the standard.
• It does not cover digital assets. Cryptocurrencies such as Bitcoin or Ethereum are increasingly relevant in financial systems but have no ISO 4217 code.
• It says nothing about display formatting — whether a symbol precedes or follows the amount, what the thousands and decimal separators are, or how the fractional unit is labelled.
• It does not specify rounding conventions — whether a calculation result should be rounded up, down, or to the nearest unit.

ORE Studio extends the ISO 4217 model with additional fields to cover these gaps: monetary nature, market tier, currency symbol, fraction symbol, a printf-style format string, and configurable rounding rules. The standard fields remain primary; the extensions are supplementary.

With the underlying model in place, both the standard fields ISO 4217 provides and the extensions layered on top of them, the rest of the chapter turns from what a currency record contains to where you go to work with one. That begins, as it does for any list-backed entity in ORE Studio, with the window listing every currency the tenant holds.

Open the Currencies window from the Reference Data menu. It lists all currencies defined in the tenant, with one row per currency.

The toolbar buttons reload the list and adjust the display. The list is paginated; use the page controls at the bottom right to navigate. Double-clicking a row opens the Currency Details dialog.

The Currency Details dialog has four tabs: General, Formatting, Rounding, and Provenance. The three action buttons at the bottom — Delete, Close, and Save — apply to the currency as a whole.

To edit a currency, open it in the Currency Details dialog, make your changes, and click Save. Before the record is written, ORE Studio prompts for a change reason.

Select a Reason from the drop-down and add optional Commentary. Click Save to confirm. Every save creates a new version; the previous version is never overwritten.

To view the full change history, open the details dialog and click the history icon in the title bar, or right-click the row and choose History.

Pick the two versions to compare from the Compare drop-downs. The All Fields / Only Changes toggle switches between showing every field and showing only the fields that differ between the two selected versions. The Revert button reinstates any historical version as a new version, preserving the full audit chain.

The three tables described in this section act as classification vocabularies for currencies. In a standard deployment their values are fixed at provisioning time and rarely change; ORE Studio still versions and audits them the same way as any other reference data. They are managed by the system tenant and are accessible from the Reference Data → Currencies sub-menu.

The ORE Studio interactive shell provides quick currency access without opening the Qt UI:

# List all currencies (paginated)
currencies get

# Add a new currency:
#   <iso_code> <name> <numeric_code> <symbol> <fractions_per_unit>
#   <change_reason_code> <change_commentary>
currencies add XTS "Test Currency" 963 T$ 100 system.test "manual example"

# Delete a currency by ISO code
currencies delete XTS

# Show history for a currency
currencies history USD

The ores.cli command-line tool provides a richer interface for automation. All currency commands live under ores.cli refdata currencies:

# List all currencies as a table
ores.cli refdata currencies list --tenant "$ORES_TENANT" --format table

# List a specific currency as JSON
ores.cli refdata currencies list --tenant "$ORES_TENANT" --format json --key EUR

# Add a new currency
ores.cli refdata currencies add \
  --tenant "$ORES_TENANT" \
  --iso-code XTS --name "Test Currency" \
  --numeric-code 963 --modified-by operator \
  --currency-type fiat

# Delete a currency by ISO code
ores.cli refdata currencies delete --tenant "$ORES_TENANT" --iso-code XTS

# Export all currencies to a file
ores.cli refdata currencies export --tenant "$ORES_TENANT" --output currencies.json

The chapter set out to show that managing a currency well follows from understanding its identity, the extensions that make it usable, its interface, and its programmatic equivalents in turn, and it has traced exactly that path. Its own birth-to-retirement lifecycle set the background the rest of the chapter operates against. ISO 4217 supplies the standard identity — code, numeric code, name, and minor units — while ORE Studio's extensions cover what the standard leaves out: market tiers, monetary natures for digital assets, display formatting, and rounding conventions. Building on that, the Qt interface took the record from the list view down to a single detail dialog and through the editing and history workflows, where reverting to an earlier version demonstrated the bitemporal audit trail keeping the full record intact. The three auxiliary classification tables then fixed the vocabulary a currency may reference, and the shell and CLI reproduced the same operations for scripted use. Currencies are the template: subsequent entity chapters follow this same progression.

• Currency Lifecycle — the domain-knowledge note this chapter's Currency lifecycle section is drawn from.
• ISO 4217 Currency Codes — the international standard for currency identification.
• SIX Financial Information — the ISO 4217 maintenance agency.
• MSCI Market Classification — framework for developed, emerging, and frontier market designations.