On June 24, 2026, Modern Treasury announced a partnership with Sardine that moves fraud checks closer to the money movement. The combined system watches payments across ACH, wire, RTP, FedNow, push-to-card, and stablecoins, and it records every one of them against a single auditable ledger. That last detail is the part many candidates overlook, and it is the exact focus of a payments PM interview. If you can explain how a ledger tracks money as it moves, you can answer most system design questions in this space.
What a ledger actually is
A ledger is a record of money and its location. In payments, the standard form is a double-entry ledger. Every event creates at least two entries that must sum to zero. One account gets a debit, another gets a credit, and the two sides hold the same total. This is the same idea a bookkeeper has used for centuries, now running inside software at high volume.
Think about a simple transfer. A customer sends fifty dollars to a merchant. The ledger debits the customer balance and credits the merchant balance. Nothing leaves the system by accident, because the entries stay in balance. When something looks off, you find it by checking whether the two sides agree, a step called reconciliation.
The accounts you will need to name
Before you draw entries, you need accounts. A payments system usually has a customer account, a merchant account, a fee account for your revenue, and a settlement account that faces the bank. Some designs add a reserve account that holds funds against future refunds. Interviewers like to hear you name these up front, because the accounts form the frame for every later entry. When you add a fee, you debit the customer or merchant and credit the fee account, and the ledger holds its balance.
The states money moves through
Money movement is not instant, and interviewers want to see that you know the gap. A card payment has an authorization, then a capture, then a settlement, then a payout. Each stage has its own timing and its own risk. Your ledger has to represent money that is promised but not yet received, money that is in flight, and money that has reached its destination. Interviewers often ask how you would model a payment with an authorization and no capture. The answer is a pending entry that later becomes a posted entry. A refund runs the same path in reverse, and a chargeback pulls money back after settlement. Your model has to handle both without losing track of the original payment.
Idempotency and why it matters
Networks fail, and the same request can arrive as a duplicate. If your system books a payment twice, you have double-counted someone's money. Interviewers ask about this problem because it shows whether you have worked on a live payment system. The fix is an idempotency key, a unique token attached to each request. When the same key shows up again, the system returns the first result instead of creating a second entry.
Reconciliation and the outside world
Your internal ledger is one view of the truth, and the bank keeps its own record. Reconciliation is the daily job of matching your records against the bank statement, the card network file, and the stablecoin chain. When the numbers disagree, someone has to find the break. A common break is a payment that your ledger shows as complete, while the bank file reports a return on the next business day. Your system has to catch that return and post a reversing entry, or your books drift from the bank over time. A payments PM has to design for this reality, because money that your system marks as moved may still sit in an intermediate account. The Modern Treasury and Sardine work is useful to study here, since it ties fraud signals to the same ledger that handles reconciliation.
How stablecoins change the model
Stablecoins add a twist worth a mention. With a card or an ACH transfer, the money is an instruction to update balances at two banks. With a stablecoin, the value moves on a blockchain, and settlement is close to final within minutes. That speed changes your ledger design, because the window where money sits in flight shrinks to a smaller gap. It also changes reconciliation, since the chain itself is a public record. Interviewers now expect a payments PM to hold both models in mind.
How to structure your answer
When you get a ledger question, start with the money before the tables. Name the accounts, name the events, and show the entries behind each event. Then walk through failure: a dropped network call, a duplicate request, a refund after a chargeback. Say how each case keeps the ledger in balance. Close with reconciliation, because that is the place where a real system proves its accuracy.
A few things to study before the interview
Read one primer on double-entry accounting, since the vocabulary comes up in every loop. Learn the card payment lifecycle from authorization to payout, and be ready to sketch the diagram. Understand idempotency well enough to explain it without notes. Look at how a ledger API models money, and Modern Treasury publishes documentation for its ledger. Practice one full design out loud, from the first entry to the final reconciliation.
A payments PM interview rewards people who can hold the money in their head and follow it through every state. The Modern Treasury and Sardine announcement is a reminder that ledgers, fraud, and settlement now sit in one system. Learn how that system keeps every entry in balance, and you will have a clear answer for most of the interview.