The database column was defined as DECIMAL(18,4). The new tokenized asset standard required 18 decimal places. When the product team tried to transfer a fractional unit in user acceptance testing, the database rejected it. The engineering team pointed to the column definition. The product team pointed to the product mandate. Nobody had an answer because the precision requirement was never treated as a product requirement.
Every decimal choice in a financial schema was made by someone with a specific product in mind. Four decimals because the fund accountant needed it for net asset value per unit. Two decimals because that is what fiat currency uses. Zero because equity shares were whole numbers. Those choices were correct at the time. The problem is that the schema outlives the product rationale, and the rationale is rarely documented. A column definition like DECIMAL(18,4) is not just a data type; it is a promise about the future that nobody remembers making.
Changing a core ledger column from four decimals to eight is a trivial database command. The complexity lies in the ripple effect. The ORM layer needs updating. The middleware message queues must support the new payload size. The downstream data warehouse must accommodate the wider columns. A third-party reconciliation engine might hard-crash when it receives eight decimal places via a fixed-width flat file.
The blast radius extends into the serialization layer. Standard JSON does not natively support fixed-precision decimals. When high-precision financials are serialized to JSON without being cast as strings, the receiving parser often defaults to floating-point representation. A trade for a highly precise fractional unit loses its final digits in transit. The database records the altered value. The daily reconciliation run fails, and the engineering team spends three days tracing the drift to a single configuration flag in a messaging parser.
When an API receives a payload with more precision than it can handle, it can throw an error and reject the message, or it can silently truncate the data to fit its schema. Loud failure stops settlement. Silent truncation creates a reconciliation break that grows over time.
Consider an FX desk quoting a currency pair where the spot rate has eight decimals. The rate table stores eight decimals, which is enough for the rate. The calculated amount is stored in a column with four decimals. The product of an eight-decimal rate and a two-decimal notional produces a result that needs more than four. The system truncates. The confirmation goes to the counterparty with the truncated amount. The counterparty’s system recalculates and gets a different number. The break is small, but it happens every day, and a fraction of a cent across a million trades becomes a material reconciliation break.
Two systems can agree on the number of decimal places and disagree on how to round. Half-up, half-even, truncation. The choice is often arbitrary and undocumented. A regulatory report might require assets to be reported in the base currency with no decimals. The platform stores amounts with four decimals. The reporting system rounds half-up. The accounting system rounds half-even. The difference is a fraction of a cent per line item. At the scale of a pension fund with millions of positions, the aggregate difference is material. The regulator will not accept different rounding modes as an explanation for a discrepancy in the final report.
Sometimes the database is not the bottleneck. A large asset manager acquires a mandate that includes fractional share trading. Their internal systems are updated, but their external custodial platform hardcodes equity quantities as integers. The vendor refuses to alter their schema for a single client. The asset manager builds a translation layer that maintains fractional balances internally while sending rounded whole-number positions to the custodian, manually reconciling the orphaned fractions in a separate database.
The limits also hide in the presentation layer. A new high-precision FX trading desk launches with backend systems correctly configured for six decimal places. The frontend trading terminal uses a generic grid component that defaults to formatting all numeric columns to two decimal places for readability. A trader executes a massive block trade based on a truncated price they see on screen. The rounding difference on a multi-billion unit notional wipes out the expected margin for the desk.
Auditing precision assumptions requires mapping the entire data lineage. Start with the instruments and currencies the platform currently supports. Determine the required precision at each stage: price, quantity, gross amount, net amount, base currency equivalent, and reporting value. Map those requirements to the columns that store them. The limits hide in ORM configurations, API gateway validation rules, message queue parsers, and vendor data ingestion scripts.
Price precision, quantity precision, and settlement precision are three different decisions. A single precision for all three is a compromise that will fail for some instrument. Calculate with more precision than you store. Round once, at the end, according to a documented policy. The policy should be explicit, not embedded in a data type.
When passing high-precision numerical data across REST APIs or message brokers, pass the value as a string. This prevents intermediary JSON parsers from silently converting the value to a floating-point number. When a system receives more precision than it can store, the behavior must be explicit. Whether the system rounds up, rounds down, uses bankers’ rounding, or rejects the payload entirely is a compliance issue, not a developer choice.
Test data rarely reaches the boundary because user acceptance testing relies on round numbers, while production uses real numbers with more decimals. The boundary is never tested because the test data does not exercise it. Testing for precision failures requires boundary values. Use the smallest representable quantity, the largest, the value with the most decimal places the instrument allows, and the value that produces a repeating fraction. Test the interfaces between systems with values that exercise the precision mismatch. Test the full lifecycle: allocation, corporate actions, valuation, cash posting, outbound transfer, reversal, replay, and reconciliation.
The database alteration takes five seconds, but finding every downstream system that relies on that schema takes five months. The schema was correct for the product that existed when it was written, which means the organization now has to decide how to pay for the products it actually wants to build.