TRY, FX and Rounding in Travel Pricing Systems
Model FX source, TRY conversion, rounding, quote timestamps and stale-rate risk for production travel pricing in Turkey.
A Turkey travel-pricing system needs more than “convert USD to TRY.” FX source, quote timestamp, buy/sell/mid semantics, rounding, supplier currency and booking-time reprice can all produce different TRY totals for the same product.
What an indicative TCMB rate means
The Central Bank of Turkey publishes indicative exchange rates on business days. It also states that these rates do not bind private parties to use them for transactions. “TCMB rate” should therefore not be assumed to equal the booking conversion rate.
Currency model
Money
├─ amount
├─ currency
└─ precision
FxQuote
├─ baseCurrency
├─ quoteCurrency
├─ rate
├─ source
├─ quoteType
├─ observedAt
└─ validUntilA converted price should preserve originalAmount and the applied FX quote reference.
Source of truth
If a supplier sends EUR and a seller displays TRY, there are three different values: supplier source amount, conversion quote and displayed/charged TRY amount. Overwriting them into one number destroys reconciliation.
Rounding
Round as late as possible at the display/settlement boundary. Rounding each component before summing can differ from converting the total once.
Hotel net EUR
+ tax EUR
+ fee EUR
→ total EUR
→ FX conversion
→ TRY roundingThe calculation order should be explicit.
Freshness
FX TTL and travel-offer TTL are separate. A supplier offer might be valid for ten minutes while the FX policy uses another horizon. Booking/reprice should decide independently which state must be refreshed.
Parity and comparison
If providers apply different FX policies, a converted TRY difference may not be a true rate-parity violation. Where possible, compare source currency or reproduce both offers using a controlled FX quote at the same timestamp.
Failure modes
Common failures include stale FX, reversed currency pair, buy/sell confusion, precision loss, cumulative rounding, weekend/holiday quote reuse, mixing new FX with an old offer and confusing display with settlement currency.
Observability
Track FX age, conversion delta, source/display currency, booking-time FX change, rounding delta, provider currency mismatch and unsupported pairs.
Production checklist
- Preserve original currency and amount.
- Store FX source and timestamp.
- Make pair direction explicit.
- Version rounding policy.
- Separate display and settlement currency.
- Define weekend/holiday behavior.
- Define reprice FX policy.
- Make parity reproducible with controlled FX.
Are you facing this in production?
We can review the symptom, data flow and integration behavior technically.