Execution and Settlement Happen on Different Days

In one line

Shares do not change hands at the moment of execution — the payment and the securities actually move two business days later, and the unsettled balance that lives in those two days explains half of a securities system.

Why this was needed

When you first look at a brokerage system, there is a table that does not make sense. There is a trade table and a settlement table, and the counts differ. There seems to be no reason to write the same thing twice, so why are they split? The answer is because the two events happen on different days.

T일    주문이 체결된다. 계약이 성립한다.
       이 시점에 오간 것은 없다. 채권과 채무만 생긴다.
T+2일  대금과 증권이 실제로 오간다. 이것이 결제(settlement).

The 2 in T+2 is not two calendar days but two business days. If you execute on a Friday, settlement is on Tuesday, and if a public holiday falls in between, it slips one more day each. This single line is a frequent cause of incidents. A settlement date calculator built with calendar addition is right for months in the middle of ordinary weekdays and wrong only around long holidays. That is why the incident happens not right after a deployment but the week after a major holiday.

Why not settle immediately? If you moved payment and securities for each of tens of millions of executions a day, neither the system nor the funds could bear it. So a day's worth is gathered and netted, and only the net amount is moved. If the same person bought 100 shares of the same symbol and sold 80, what actually moves is 20 shares. This netting work is clearing, and settlement goes out only after it finishes. That time is what T+2 really is.

How it works

Reconciliation is the work of matching the trade book against the settlement book. The knack is to count four directions separately.

양쪽에 있고 금액도 같다        정상
양쪽에 있는데 금액이 다르다    수수료 규칙 차이거나 진짜 오류
체결에는 있는데 결제가 없다    지시가 안 나갔거나 유실됐다
결제에는 있는데 체결이 없다    남의 배치가 우리 것에 섞였다

This is why a reconciliation that compares only count totals is dangerous. With 1,200 trades and 1,152 settlements it looks like a difference of 48, but in reality 60 have no settlement and 12 have no trade, so 72 are off. The differences in the two directions canceled each other and merely looked like 48. Amount totals cancel out in the same way. So reconciliation must always be done per record, in both directions.

A settlement fail is an item whose settlement date has passed but which has not finished. You must put a date condition in the judgment — if you count even items whose settlement date has not yet arrived, the fail balance inflates, and if you recompute margin from that number, perfectly good accounts get frozen. And you must split by reason.

결제 기록 자체가 없다   지시 생성 쪽 문제. 원인이 우리 안에 있다
아직 pending 이다        상대방이나 예탁결제원 쪽 진행 중
failed 로 끝났다         잔고 부족·계좌 문제. 고객 연락이 필요하다

The three belong to different departments. If you report only "120 fails" in total, nobody takes it as their own job.

What it looks like in the field

At one site, the week after the Chuseok holiday, the fail balance jumped to three times normal. It took three days to find the cause, and the cause turned out to be that the settlement date calculator did not know about a temporary public holiday. The holiday table was hard-coded as a constant in the code, and that year's temporary holiday was designated after the deployment. If you keep holidays as data rather than code, they take effect without a deployment.

Another thing you often see is a trade whose settlement date was recorded as a day that is not a business day at all. Settlement does not happen on that day, so the instruction just flows along, and the next day nobody picks it up and handles it either. It stays as a fail quietly and is found days later in a balance check. A single line of checking whether the settlement date itself is a business day catches this whole category.

If a fail is left alone, it ends up in a buy-in. If you cannot deliver the securities you agreed to sell, the clearing house buys them in the market on your behalf, delivers them, and bills the failing side for the cost. The amount is large and the purchase is at the market price, so the loss is unpredictable. A one-line bug in the settlement date calculator can go that far.

What you will do in the lab that follows

First, the next reading covers card authorization and capture, and then you move on to the lab.

You build a ledger containing 1,200 trades and 1,152 settlements, read the holiday table to recompute T+2 on a business-day basis, and find the trades whose settlement date is wrong. Then you reconcile the two books in four directions, split the items whose settlement date has passed but which are not finished by reason, and produce the amounts as well.