Risk and Regulation — The Why Behind the Requirements
In one line
A bank does business with other people's money, so it is subject to heavy regulation spanning capital, credit review, anti-money-laundering, electronic finance, and consumer protection, and a good part of that regulation comes down as IT requirements.
Why regulation becomes IT requirements
Bank system requirement documents are full of items that seem unrelated to function. "Keep transaction logs for 5 years," "store access records separately," "do not expose the fact of an STR filing on screen," "record whether the duty to explain was fulfilled." All of these came from regulation. A bank lends out deposits, which are other people's money, so if it fails, depositors and the whole payment system are at risk. So the state makes banks build up capital, leave procedures on record, and report. The reason IT staff need to know the backbone of the regulation is that the "why" of the requirements is there.
Capital and risk — the BIS ratio and Basel
What lets a bank absorb losses is its own capital. The international standard (the Basel Committee) requires a ratio of own capital to risk-weighted assets. Because each loan has a different risk, even the same 10 billion won has a different risk weight for government bonds and for personal credit loans, and their weighted sum is the risk-weighted assets. The Basel III minimum total capital ratio is 8%, and with the capital buffer added, the working standard is roughly 10.5%, and there is a separate minimum for high-quality capital such as common equity tier 1 (CET1). For IT, this comes down as "you must be able to attach a risk weight to every loan and aggregate it every day."
Credit review — the 5 Cs
What has long been used as a framework for deciding whether to grant a loan is the 5 Cs.
| 5C | What it looks at |
|---|---|
| Character | Willingness to repay. Credit history, delinquency records. |
| Capacity | Ability to repay. Income, cash flow, existing debt (indicators such as DSR come from here). |
| Capital | Own capital. How much of their own money the borrower has put in. |
| Collateral | Security. What can be recovered if the loan is not repaid. |
| Conditions | Conditions. Interest rates, the economy, the industry environment. |
The data items of a review system are mostly classified into these five branches. Even as credit scoring models become more sophisticated, the framework is the same.
Anti-money-laundering — AML/KYC
A bank must identify its customers (KYC), monitor transactions, and report if something is suspicious. In Korea, the law that sets this obligation is the Act on Reporting and Using Specified Financial Transaction Information (the Specified Financial Information Act), and the institution that receives the reports is the Korea Financial Intelligence Unit (FIU).
| Obligation | What it requires |
|---|---|
| CDD/EDD | Customer due diligence. Verify identity and the beneficial owner, with enhanced checks for high-risk customers. |
| CTR | Currency transaction report. Cash deposits or withdrawals at or above a daily threshold (currently 10 million won) are reported as such. |
| STR | Suspicious transaction report. Reported whenever money laundering is suspected, regardless of amount. Judgment is involved. |
| Confidentiality | The customer must not be told that a report was made. |
The IT requirements are clear. Data on which the transaction monitoring rules can run, customer risk ratings and verification dates, isolation of report history, and a design in which the fact of a report does not leak into customer screens, notifications, or consultation records.
Electronic finance and consumer protection
The Electronic Financial Transactions Act deals with the safety of non-face-to-face transactions. The core is the management of access media (certificates, OTPs, and so on), the creation and retention of transaction records, the sharing of responsibility in case of an accident, and the duty to ensure security. The details are set by the Regulation on Supervision of Electronic Financial Transactions, but provisions such as network separation and the ratio of information security staff and budget have been undergoing relaxation and reorganization over the past few years, so you have to check the regulation in force at the time to know what is valid now. The Financial Consumer Protection Act deals with sales procedures. Its backbone is six principles — suitability, appropriateness, the duty to explain, a ban on unfair business practices, a ban on improper solicitation, and advertising regulation — and for IT it comes down as "leave a record of the fact that you explained and the fact that the customer confirmed."
Internal control and information security
Laws on the governance of financial companies require internal control standards, and recently a responsibility map, which documents each executive's scope of responsibility, has been introduced. On the information security side, access control, separation of privileges, log retention, and vulnerability inspection are required by supervisory regulations, and for personal information, the Personal Information Protection Act and the Credit Information Act apply overlappingly. For IT staff this means "you must record who saw what and when, separate developer and operator privileges, and be able to present that evidence to an audit."
The traces regulatory requirements leave in systems
Regulatory documents are long, but when they come down to systems they turn into a few recurring requirements. If you know their shape, you will know what to ask even when a new regulation arrives.
Do not delete records. In AML investigations, disputes, and audits, the question asked is "what was the value at that time?" A table that is updated cannot answer that question, so for important data accumulate history and compute the current value.
Reproducibility of calculations is required. For numbers such as the capital ratio or provisions, the demand comes to "show how it was derived." If you store only the result, you cannot reproduce it months later. Leave the inputs, reference date, regulation version, and code version along with the result.
A person judges a suspicious transaction, and that judgment is recorded. If you block automatically, normal transactions get blocked, and if you pass automatically, you miss the reporting duty. The system's role is to narrow the candidates, put them in front of a person, and leave that decision on record.
Customer verification is periodic, not one-time. The re-verification cycle differs by risk rating, and the rating changes with transaction behavior. So KYC is designed not as a sign-up screen but as a batch that keeps running.
Reports have deadlines. Being late or having the wrong format is itself a violation. A failure of a reporting batch has to be known as fast as a service outage, and there must also be a resubmission path.
Separate privileges. If the person who creates transactions and the person who can edit those records are the same, that itself is a finding. If there is still a path by which developers connect directly to the production database, this is usually where it gets caught.
There are three things a developer should ask. What is the reference date of this value, by which version of the regulation was it calculated, and does recomputing give the same value?
What really matters in practice
First, regulatory requirements have reasons. If you ask "why do we keep this log for 5 years?" there is an answer, and if you know the answer, how far to keep is determined too.
Second, numbers and provisions change. Ratios, limits, and retention periods move with amendments. Do not hard-code them as constants in code; keep them in a policy table and write the basis regulation alongside.
Third, write an STR as facts. A rule engine's output is a basis for judgment, not a conclusion, and the report contains the transaction number, amount, date, and rule. And that fact must not leak to the customer.
In the next lab, you will implement five detection rules directly to produce alert scores and write the report draft from facts only.