Market Hours Govern the Batch Schedule

In one line

The batch schedule, log format, and retention period of a securities system are not things engineers chose but things set by market operating hours and regulation, and if you do not know that, you end up making suggestions like "can't we push this batch back 30 minutes?"

Why this was needed

When you join a brokerage and first look at the batch schedule table, it looks strangely dense. Things are packed at 08:30, 08:40, 09:00, 15:20, 15:30, 15:40, and 16:00, and the times in between are empty. A suggestion to spread the server load evenly is natural, but there is a reason it does not work.

Every one of those times is tied to a market rule.

08:30~09:00  장 시작 동시호가. 주문을 받되 체결은 하지 않는다
09:00        정규장 개시. 첫 체결이 쏟아진다
15:20~15:30  장 마감 동시호가. 종가를 정하는 구간
15:30        정규장 종료
15:40~16:00  시간외 종가 매매
장 종료 후    청산·결제 지시, 잔고 확정, 보고 파일 생성

The call auction matters especially. During this window orders keep being accepted but are not executed; they are gathered, and at the closing time they are all executed at a single price at once. From the system's point of view, this means order intake load and execution load are separated in time and then pile up at one point. At 09:00:00 and 15:30:00, throughput per second jumps to dozens of times normal. If you size capacity by the average, it collapses at these two points.

And these times are not negotiable. A closing price that has to be fixed at 15:30, if fixed at 15:31, throws off the settlement prices of every derivative that day. That is why the suggestion to "push the batch back 30 minutes" does not work.

How it works

Circuit breakers and volatility interruption (VI) are especially troublesome from the system-load point of view. When the index falls by more than a set amount, trading stops for several minutes, and when an individual symbol's price moves sharply, only that symbol is briefly switched to single-price trading.

In terms of load, this is what happens. While trading is halted, orders keep coming in and pile up in the queue, and at the resumption time they are released all at once. Several times the usual peak piles up at a single point, and that point cannot be predicted. That is why capacity sizing for securities systems customarily leaves headroom of "several times the normal peak," and if you judge that headroom to be waste and cut it, you pay on the day a circuit breaker trips.

The obligation to retain order records. The Capital Markets Act and its subordinate regulations require order and execution records to be kept for a set period (usually 10 years). The mark this leaves on a system is not simply "it uses a lot of disk."

원본 그대로 보존해야 한다   가공한 것으로 대체할 수 없다. 그래서
                            정규화된 테이블과 원본 로그가 둘 다 남는다
변경 이력이 남아야 한다     덮어쓰기가 아니라 append 로 쌓는 구조가 된다
조회 가능해야 한다          분쟁이나 조사에서 특정 주문을 꺼내야 하므로
                            아카이브에도 색인이 필요하다

This works in your favor when investigating. Originals that would already have been deleted in other domains usually still exist in securities. This retention obligation is why the advice to not trust the status field and to rebuild it from the originals is actually doable.

Market surveillance (abnormal-trading detection) dictates the log format. A surveillance system looks for patterns such as whether a particular account repeatedly placed and canceled quotes on a particular symbol, or concentrated orders around the close. To see such things, canceled orders and unexecuted quotes must all remain. So the optimization "it is a canceled order anyway, so let's drop it from the log" is impossible in securities. The account identifier, order time, and amendment history being mandatory fields is also because of surveillance requirements.

What it looks like in the field

One site, to reduce the retention cost of order logs, introduced a policy of deleting unexecuted, canceled orders after 90 days. They were cited in an audit and reversed the policy, but what had already been deleted could not be recovered when they reversed it. Before putting an irreversible optimization into a regulated area, you must always ask compliance first. This is not the kind of judgment an engineer can make alone.

Another thing: when you connect to overseas exchanges, each market has its own time zone and its own holidays. When Korea is on holiday the US market is open, and vice versa. A common incident here is cutting the date by the server's local time zone. If you cut the day at UTC midnight, it is off from the Korean day, and executions right after the close fall into the next day's batch. That day's tally and the next day's tally are both wrong, and because the total is right, reconciliation does not catch it either. The date boundary must be stated explicitly by the market's business day.

Where regulation comes down as system requirements

Capital markets regulation is long as a document, but when it comes down to the system it turns into a few repeating requirements. If you know their shapes, you know what to ask when a new regulation arrives.

First, immutability of records. Orders, amendments, cancels, and executions are kept with their timestamps and must not change afterward. That is why the table becomes an append-only table, not an updating table. You must be able to reproduce "what did we know at that time."

Second, timestamp accuracy. The precision required differs by regulation (milliseconds, microseconds). To record at that precision, clock synchronization itself becomes a requirement, and the periods when synchronization broke must also be recorded.

Third, reconstructability. You must be able to rebuild the order book and order states at a particular point in time. That is why snapshots and increments are kept together, and the retention period becomes the storage cost.

Fourth, authority and separation. The person who places orders and the person who can change those records must be different. If a developer can connect directly to the production database, that in itself becomes a finding.

Fifth, reporting deadlines. You must deliver by a set time in a set format, and being late or wrong is itself a violation. That is why a mechanism for humans to learn immediately when a reporting batch fails becomes as important as incident response.

The three questions a developer should ask are always the same. What is the reference time of this value, what inputs was it computed from, and if you compute it again will you get the same value? If you can answer these three, the rest gets settled in conversation with the compliance officer.

Finally, regulatory compliance is a constraint, not a feature. If you add it later, you have to change the structure. The habit of checking records, time, and reproducibility first when designing a new feature lowers the cost later.

What to check in the next quiz

You check the effect of the call auction on load, how the queue clears at the circuit-breaker resumption point, the marks the retention obligation leaves on data structures, how market surveillance dictates the log format, and how to handle time zones and business-day boundaries.