[KRW] Add Bank of Korea (BOK-Wire) settlement holiday calendar (blocked — needs primary-source data)

[davejoyce]

Module(s) Affected

holiday-calendar-apac

Problem / Motivation

No Korean won (KRW) settlement calendar exists in this library. Research for this milestone could not find a primary source for Bank of Korea's BOK-Wire (RTGS) settlement holiday calendar — only a generic description that it likely aligns with national public holidays, with the Dec 31 KRX market-only closure status unconfirmed for the settlement system specifically. Shipping a guessed settlement calendar risks being actively wrong for downstream date-math in a way that's worse than not shipping at all.

Proposed Solution

This issue is intentionally blocked pending primary-source data, though follow-up research has narrowed the remaining gap. Do not implement from the "presumed = national calendar" guess.

Confirmed (2026 follow-up research), from the Bank of Korea's own official site (bok.or.kr Payment and Settlement Systems page) and the BIS CPSS Red Book country report for Korea: BOK-Wire+ operates weekdays only (09:00–17:30) and closes on South Korea's national public holidays. This is a real primary-source confirmation of the general operating principle — BOK-Wire follows the KR national holiday calendar — but it is not the same as having an actual published multi-year date list, and it does not resolve the Dec 31 question below.

Still blocked on:

• December 31 status — genuinely ambiguous, do not assume it mirrors XKRX. Follow-up research found signals that clearing/settlement infrastructure (e.g., CCP central counterparty clearing) reportedly continues operating normally on Dec 31 even in years when KRX's equities market itself is closed for its market-only year-end closure. This directly cuts against copying XKRX's Dec 31 closure onto KRW — settlement and trading are different systems here, the same way HKD CHATS and HKEX are different systems. Needs an explicit Bank of Korea or KFTC (Korea Financial Telecommunications & Clearings Institute) statement on BOK-Wire's Dec 31 operating status specifically, not inference from KRX's schedule.
• Obtain an actual multi-year (2022–2026 or later) list of BOK-Wire non-operating dates, not just the general "closed on national holidays" principle — no such list was found published anywhere in either research pass
• Confirm whether BOK-Wire has any deviations from the plain KR national holiday + daecheday-substitute list beyond the Dec 31 question (none found so far, but the general-principle source doesn't rule out edge cases)
• Note the planned BOK-WireInt transition (pilot September 2026, full deployment January 2027) — confirmed this is a separate, offshore-focused system, not a holiday-calendar change to BOK-Wire proper, so it does not currently affect this calendar's scope; revisit if that changes

Once primary-sourced on the Dec 31 question specifically, implementation should follow the KR/XKRX shape: reuse KRHolidays as the base list (now reasonably well-supported by the confirmed general principle), with the Dec 31 entry included or excluded based on whatever the Bank of Korea/KFTC source states.

Alternatives Considered

Considered shipping with a "presumed = national calendar" caveat and a loud Javadoc warning rather than blocking entirely. Rejected for the same reason as the parallel HKD decision: the project just completed a remediation cycle (#229/#231-#241) specifically because previously-shipped calendars baked in unconfirmed assumptions as if verified. Blocking until real data exists is consistent with that lesson — and the Dec 31 ambiguity found in the 2026 follow-up research is a concrete example of exactly the kind of wrong guess that discipline is meant to prevent (naively copying XKRX's market closure onto the settlement calendar would likely have been incorrect).

Additional Context

• Parent: [KR] Add South Korea holiday calendars (national + market + settlement) #256
• Related: [KR] Add South Korea national holiday calendar #260 (KR), [XKRX] Add Korea Exchange (KRX) market holiday calendar #261 (XKRX)
• Labeled to make clear this cannot be picked up as a normal "good first issue" — it requires external data acquisition first, not just implementation.