Rupiah Redenomination: Can We Remove Three Zeros Without a Full System Crash?

As an iOS engineer working in the Indonesian banking sector, I spend a lot of time looking at zeros. A lot of zeros.

If you’re a foreigner visiting Jakarta, the first thing you notice is that you become a millionaire the moment you exchange $100 USD. You buy a coffee for 50,000, a decent lunch for 150,000, and a used motorbike might cost you 15,000,000.

For years, there has been a rumor, and now a recurring legislative draft (RUU) about Redenomination. The plan is simple in theory: remove three zeros.

Old: Rp 1,000
New: Rp 1

While the politicians talk about “economic efficiency” and “pride”, my developer brain immediately goes into panic mode. How on earth are we going to migrate a live banking system without breaking everything?

I recently had a discussion with my colleague, Martinus Andika Novanawa, about this topic. That conversation helped me realize that this transition is more complex than I first expected. Because of that, I wanted to write this article to take a deeper look at how this change could affect our system, not only at the mobile application level, but also all the way down to the database layer.

Disclaimer: I am an iOS software engineer, not a financial analyst. The thoughts below are purely technical speculations based on how we usually build banking ledgers. If you have a finance background, I’d love your corrections!

The iOS Perspective: More Than Just String Replacement

You might think, “Just change the display logic, right?” If only it were that simple.

1. The `NumberFormatter` & Input Masks

Currently, most Indonesian apps (especially e-wallets and banking) are optimized for integers. We rarely deal with sen (cents) because Rp 0.5 doesn’t effectively exist in cash right now.

Current State: User types 10000. We mask it to Rp 10.000.
Future State: If 1,000 becomes 1, then Rp 500 (the coin) becomes Rp 0.5.

Suddenly, we need to support decimals in input fields where we previously hard-blocked them. If you are using a third-party library for currency masking that doesn’t support flexible decimal precision, you might have to rewrite your entire input logic.

2. Screen Real Estate & UX Psychology

This is interesting. Right now, our UI is designed to handle long strings. Rp 15.000.000 takes up a lot of horizontal space.

If that becomes Rp 15.000, our layouts might look weirdly empty.

But the bigger risk is User Panic.

Imagine a user logs in and sees their balance drop from 100,000,000 to 100,000. Even if we put a banner up, the lizard brain will panic.

The Fix: We will likely need a “Dual Display” mode for a transition period (6-12 months).

Balance: Rp 10.000 (Old: Rp 10.000.000)

The Backend: Where the Real Danger Lies

While I fix the UI constraints, the backend team has a much scarier job.

1. Data Types & Precision

In banking, we never use floating-point math (because 0.1 + 0.2 != 0.3 in standard binary floating-point). We use Decimal or BigInt representing the minor unit.

You might want to check about floating-point math on my other writing here Using Double (or Float) in a Banking App? That’s How Money Disappears.

Currently, if we store Rp 10,000, we might store it as 10000 (if ignoring cents) or 1000000 (if storing as cents, though rare in IDR).

If we redenominate, Rp 0.5 becomes a valid transaction.

Option A: Change the scale. If we used to store Integer, we now must migrate to Decimal(18, 2) or keep using BigInt but effectively shift the decimal point representation.
Option B (The Nightmare): Mixed data. Some rows are “Old Rupiah”, some are “New Rupiah.” Do not do this. It is a recipe for disaster in reporting.

2. The “Cutover” Maintenance Window

Banks usually have a nightly batch process (End of Day). But a redenomination is a System-Wide Migration.

We would likely need a massive maintenance window (perhaps a whole weekend) to run a script that divides every single balance and historical transaction by 1,000.

But wait… what about rounding?

If a transaction was Rp 1,540, does it become 1.54? Or do we round it?

If we round it, the bank’s total ledger won’t balance anymore. Money will be created or destroyed by rounding errors. The system must likely support exact decimals (1.54) for historical accuracy, even if the cash doesn’t exist.

System-Wide Integration: The ISO Code Problem

This is the part that keeps me up at night.

In the international standard (ISO 4217), our code is IDR.

When countries redenominate, they usually get a new code to prevent confusion.

Mexico: MXP -> MXN
Venezuela: VEF -> VES

Will Indonesia change IDR to IDN (or something else)?

If the ISO code changes:

Payment Gateways: Every API call to Visa/Mastercard, GoPay, OVO, etc., needs to know which currency we are sending.
Hardcoded Strings: I bet there are thousands of lines of code in our legacy systems checking if currency == "IDR". These will all break.

How to Mitigate: The Strategy

If I were architecting this migration, here is my humble proposal:

Phase 1: The “Shadow” Ledger

Months before the change, we add a new column to our database: amount_new_idr.

We keep it empty or calculate it on the fly. This allows us to test conversion logic without touching the real money.

Phase 2: Feature Flagging the API

We version our APIs.

v1/balance -> returns { amount: 50000, currency: "IDR" }
v2/balance -> returns { amount: 50, currency: "NEW_IDR" }

The mobile app will request v1 or v2 based on a remote config (Feature Flag). This lets us switch users over gradually or rollout to internal staff first.

Phase 3: The Dual Currency UI

As mentioned, the app must request both values during the transition.

{
  "balance": {
    "value": 50.00,
    "currency": "IDN",
    "display": "Rp 50,00"
  },
  "legacy_balance": {
    "value": 50000,
    "currency": "IDR",
    "display": "Rp 50.000"
  }
}

Closing Thoughts

Redenomination sounds like a “Search and Replace” job, but for a bank, it’s open-heart surgery.

We have to handle:

Decimal precision re-entering our ecosystem.
Historical data integrity (modifying the past vs. displaying it differently).
Third-party chaos (what if the electric bill API switches to New Rupiah before we do?).

It’s an exciting challenge, and honestly, I’d love to see Rp 50 for a coffee on my screen. It feels… cleaner.

To my friends in Finance/Accounting:

Am I missing a crucial ledger rule here? How do you handle the “rounding creates/destroys money” issue in the General Ledger? Let’s discuss!