Security Engineering: Part 6. Financial Systems

July 10, 2026 • 23 min read • Security Engineering • #Security • 👁 28

Banking and Accounting: Why Security Is Not Only Cryptography

While previous parts focused primarily on confidentiality, here the spotlight falls on two other fundamental security characteristics: integrity and accountability.
A banking system must guarantee that money cannot be created out of thin air, deleted without a trace, or moved unnoticed. Every transaction must be verifiable, and every change in the system’s state must have a documented basis.
The main idea of this article is that the security of financial systems is determined not only by cryptographic mechanisms. An equally important role is played by accounting principles, organisational processes, economic incentives, and the distribution of responsibility among system participants.

Accounting as the Foundation of Information Security

The history of banking security began long before computers and cryptography. One of the most important inventions in this area was the system of double‑entry bookkeeping, which appeared as early as the Renaissance.
Its basic principle is extremely simple: every debit must be matched by an equal credit. Any financial transaction affects at least two accounts, and the total sum of changes always remains balanced.
For example, when transferring 100 dollars from account A to account B, the following occurs:

a debit of 100 dollars from account A.
a credit of 100 dollars to account B.

The total amount of money in the system remains unchanged.
This mechanism proved so effective for maintaining data integrity that several centuries later it became the basis for formal models of computer security.

The Clark–Wilson Model: Formalising Financial Integrity

In 1987, David Clark and David Wilson proposed a security model oriented not towards preserving data confidentiality, but towards ensuring its correctness.
Unlike the Bell–LaPadula model, which is designed to protect confidential information using clearance levels, the Clark–Wilson model focuses on maintaining the correct state of the system through controlled transactions.
The model is built on four key elements.

Component	Purpose	Example in a Banking System
UDI (Unconstrained Data Items)	Untrusted data coming from outside	Transfer amount and account number entered by the client
CDI (Constrained Data Items)	Data whose integrity must be strictly maintained	Account balances, transaction logs
TP (Transformation Procedures)	The only permitted way to change CDIs	Banking transfer procedure
IVP (Integrity Verification Procedures)	Checking the correctness of the system state	Reconciliation of debits and credits

The central principle of the model is that users cannot directly modify critically important data.
A client cannot increase their account balance on their own. Instead, they initiate the execution of a Transformation Procedure (TP), which:

Checks the user’s authority.
Validates the input data.
Ensures business rules are followed.
Performs the allowed changes.
Records the result in the audit log.

Thus, what is protected is not individual data items, but system invariants – fundamental rules that must never be violated.
For banks, the main invariant remains the double‑entry principle: the sum of all debits must equal the sum of all credits.

Internal Control: Protection Against Insiders

One of the most important conclusions of the article is that banks often suffer their largest financial losses not from external attacks, but from the actions of their own employees.
Even ideally implemented cryptography cannot prevent abuse if the organisation lacks effective internal control mechanisms.

Two fundamental principles stand out.

Dual Control

Critical operations require the participation of several employees.
For example:

issuance of master keys.
authorisation of large money transfers.
access to key storage facilities.
administrative operations on HSMs.

No single employee should be able to perform a high‑risk action alone.

Functional Separation of Duties

Different stages of a single operation must be carried out by different employees.
For example:

one employee initiates a payment.
a second confirms it.
a third performs reconciliation and audit.

This approach significantly reduces the likelihood of fraud and reduces the risk of errors.

Prevent – Detect – Recover: A Realistic Protection Model

Absolutely secure systems do not exist. Therefore, financial organisations build their protection around three complementary mechanisms:

Prevent

Measures aimed at preventing incidents:

access control.
multi‑factor authentication.
separation of duties.
cryptographic protection.

Detect

Mechanisms for identifying violations:

audit logs.
transaction monitoring.
accounting reconciliation.
fraud detection systems.

Recover

Methods to minimise consequences:

reversal of erroneous transactions.
financial risk insurance.
backup.
incident response procedures.

Practice shows that preventing all attacks is impossible. Therefore, the ability to quickly detect violations and restore the normal state of the system is often more important than absolute protection.

Insider Fraud and Suspense Accounts

A telling example of abuse involves suspense accounts – accounts used for temporarily holding transactions that require additional verification.
The fraud scheme worked as follows:

An employee initiated a fictitious transfer.
The funds were temporarily placed in a suspense account.
An accomplice withdrew the money in time.
Before the mandatory check began, the transaction was cancelled.

Since the audit took place several days after the suspicious operation occurred, the fraudsters used this time window to conceal their actions.
Such incidents demonstrate an important principle: security is determined not only by technical means, but also by the quality of organisational procedures.
Even flawless cryptographic protection is useless if an attacker can exploit weaknesses in business processes.

ATMs: The First Mass Deployment of Cryptography

The advent of ATMs was one of the first examples of the widespread introduction of cryptographic technologies into everyday life. Before that, information security measures were mainly used by government agencies and military organisations.
ATMs posed a new challenge for banks: they needed to provide customers with remote access to their accounts without disclosing secret information and while minimising the risk of fraud.
The main element of authentication became the PIN (Personal Identification Number).
However, the common belief that the PIN is stored directly on the card or in plain text in the bank’s database is incorrect.
Banking systems were designed so that even bank employees could not gain access to customers’ PINs.

How PINs Are Generated: The IBM 3624 System

One of the most influential solutions was the PIN management system developed by IBM for the IBM 3624 series of ATMs.
Its key feature was that the PIN was not stored in the database in plain text.
The process looked like this:

The card number (PAN – Primary Account Number) was taken.
The PAN was encrypted using a special PIN Verification Key (PVK).
Certain digits were extracted from the encryption result.
The resulting sequence became the so‑called Natural PIN.

For example:

PAN → Encryption with PVK → 4827316942...
                                 ↓
                         Natural PIN = 4827

Thus, the bank could recompute the PIN during verification without storing it in plain text.

PIN Offset: Allowing the Client to Choose a PIN

Most people prefer to use easy‑to‑remember combinations: birth dates, simple sequences, or other meaningful numbers.
To allow the client to choose their own PIN, the concept of PIN Offset was introduced.
Suppose:

Natural PIN: 4827
Client‑chosen PIN: 1357

The system calculates the difference between them modulo 10:

4827
1357
────
7530

The resulting value (7530) is stored in the database as the offset.
During verification, the reverse process occurs:

The natural PIN is computed.
The offset is applied.
The result is compared with the PIN entered by the client.

This approach provides several advantages at once:

the actual PINs are not stored in the database.
clients can choose convenient combinations.
compromise of the offset database does not directly reveal PINs.

Hardware Security Modules (HSMs)

To protect cryptographic keys, banks use Hardware Security Modules (HSMs) – specialised hardware devices designed to perform cryptographic operations.
Main functions of an HSM:

key generation.
master key storage.
PIN verification.
computation of cryptographic codes.
encryption and decryption operations.

The key principle of HSM operation is that secret keys never leave the device in plain text.
Even system administrators should not be able to extract them directly.
However, a significant problem should be noted: the complexity of the interfaces of such devices.
Many HSMs provide dozens or even hundreds of cryptographic commands. Errors in API design can lead to situations where an attacker, without direct access to the keys, can send a specially crafted sequence of commands and obtain critically important information.
This once again underscores an important engineering principle:

The security of a system is determined not only by the strength of cryptographic algorithms, but also by the correctness of the interfaces used to access them.

Magnetic Strips: The Era of Static Data

Early bank cards used a magnetic strip to store information.
It contained:

card number.
expiry date.
service information.
additional data for authorisation.

The main problem with this approach was the static nature of the information.
The data stored on the magnetic strip did not change from transaction to transaction.
This opened the door to mass fraud.

Skimming

The most common attack was copying the contents of the magnetic strip using specialised devices – skimmers.
Typically, criminals:

Installed an overlay reader on an ATM.
Obtained a copy of the magnetic strip data.
Captured the PIN using hidden cameras or fake keypads.
Created a duplicate card.

Since the information on the strip remained unchanged, the clone was practically indistinguishable from the original.

CVV: The First Cryptographic Barrier

In response to rising fraud, payment systems introduced the Card Verification Value (CVV) mechanism.
CVV is a cryptographically computed value based on:

the card number.
the expiry date.
the issuer’s secret keys.

The main idea was to create data that could not be correctly reproduced without knowledge of the bank’s keys.
The introduction of CVV made it significantly more difficult to create fully functional counterfeit cards.
However, this solution did not eliminate the fundamental problem of the magnetic strip: the data remained static.
The next logical step was the use of smart cards.

The Transition to EMV: The Advent of Smart Cards

The EMV standard (Europay, Mastercard, Visa) was developed as a response to the epidemic of card cloning.
Unlike the magnetic strip, chip cards contain an embedded microprocessor capable of performing cryptographic operations.
This made it possible to move from static authentication to dynamic authentication.
EMV supports several levels of card authentication.

Method	Operating Principle	Limitations
SDA (Static Data Authentication)	Verification of the digital signature of the card’s static data	Does not protect against sophisticated cloning
DDA (Dynamic Data Authentication)	Generation of a unique signature for each transaction	Does not certify the transaction content
CDA (Combined Data Authentication)	Both a random number and transaction parameters are signed	Requires a more complex infrastructure

SDA: Static Authentication

With SDA, the card contains a digital signature that certifies the authenticity of its static data.
The terminal verifies the signature using the payment system’s public keys.
The advantage of this method is its simplicity.
The drawback is the absence of a dynamic element.
If an attacker manages to replay the necessary data, the protection is significantly weakened.

DDA: Dynamic Authentication

DDA uses a challenge‑response mechanism.
The process looks like this:

The terminal generates a random number (nonce).
The card signs it with its private key.
The terminal verifies the received signature.

This proves that the card is physically present and possesses the required cryptographic secrets.
However, DDA only confirms the presence of the card, but does not protect the payment parameters themselves.

CDA: Combined Authentication

CDA is considered the most robust EMV authentication option.
In this case, the card signs:

the terminal’s random number.
the transaction amount.
the merchant identifier.
additional transaction parameters.

Forging such a transaction is much more difficult, because not only the presence of the card but also the specific content of the payment is cryptographically certified.
Nevertheless, even CDA does not provide absolute protection.
The security of the system still depends on the quality of implementation and the correctness of the surrounding infrastructure.

When Cryptography Is Powerless: Attacks on EMV Implementations

Despite significant progress achieved through the adoption of EMV, the transition to chip cards did not completely solve the fraud problem. The history of payment systems shows that attackers rarely attack cryptographic algorithms directly. Much more often, they exploit implementation errors, weaknesses in business processes, and peculiarities of interaction between system components.

Yes‑Card Attacks

One of the first serious threats to Chip‑and‑PIN systems were so‑called Yes‑cards.
The idea was to modify the card’s chip so that it would always return a positive PIN verification result.
From the terminal’s point of view, the process looked completely legitimate:

The user enters a PIN.
The terminal sends it to the card for verification.
The card responds that the PIN is correct.
The transaction continues.

If the terminal relied solely on the card’s response and did not perform additional checks on the bank side, the fraudulent transaction went through successfully.
These attacks demonstrated an important problem:

The security of a protocol is determined not only by its cryptographic strength, but also by how the verification procedures are actually implemented.

Relay Attacks

Even more telling are relay attacks.
They exploit a fundamental limitation of most authentication systems: the inability to reliably determine the physical location of a device.
The attack scenario may look like this:

attacker A is located near the victim and interacts with the genuine card.
attacker B is in a shop with a device that emulates a card.
requests from the terminal are relayed between the attackers via the internet or a radio channel.
the victim’s genuine card performs all required cryptographic operations.
the terminal receives correct responses and completes the transaction.

From the bank’s point of view:

a genuine chip was used.
cryptographic checks were successful.
the PIN was entered correctly.

Nevertheless, the transaction itself was initiated by fraudsters.
Such attacks demonstrate an important feature of modern security systems:

Cryptography confirms the authenticity of the interacting parties, but does not always guarantee the correctness of the context in which that interaction takes place.

From Telegraph to SWIFT: The History of Electronic Payments

Security problems with bank transfers arose long before computers.
As early as the 19th century, banks actively used the telegraph to transmit payment instructions between cities and countries.
However, telegraph operators could:

alter the content of messages.
forge instructions.
delay transfers.
carry out fraudulent operations on behalf of banks.

In effect, these were the first attacks on electronic payment systems.

Test Keys

To combat message forgery, banks began using special Test Keys.
They were algorithms that allowed calculating check values based on:

the transfer amount.
bank identifiers.
secret information known only to the exchange participants.

The recipient could verify the correctness of the received code and ensure that the message had not been altered.
Although modern cryptographic methods far surpass test keys in terms of protection, the very idea of message authentication remains unchanged.

SWIFT and Procedural Vulnerabilities

The modern international interbank messaging system SWIFT significantly raised the level of automation of financial operations.
However, experience shows that the most serious threats arise not from weaknesses in cryptographic algorithms, but from shortcomings in organisational processes.

The Stanley Rifkin Case

One of the best‑known examples is the Stanley Rifkin case in 1978.
Rifkin stole more than 10 million dollars without hacking the bank’s computer systems.
His scheme was surprisingly simple:

He learned the internal authorisation code for bank transfers.
He contacted bank employees, posing as an authorised officer.
He initiated a large international transfer.
He used a holiday weekend to buy time.

The main lesson from this case is:

The most sophisticated technical protection measures are useless if an attacker can bypass procedural control mechanisms.

The Economics of Security and Liability Shifting

One of the central ideas of the article is the influence of economic incentives on the level of security.
Organisational behaviour is determined not only by technical capabilities, but also by the distribution of financial risks.

Liability Dumping

In many countries, banks long adhered to the following logic:

If the card was used correctly and the PIN was entered correctly, the client bears responsibility.

This approach created a serious problem.
If the financial loss is borne by the user, the bank has little incentive to invest in:

improving fraud detection systems.
raising the quality of investigations.
developing compensation mechanisms.
improving security user interfaces.

Moral Hazard

This situation leads to moral hazard.
When an organisation does not bear the consequences of its own systems’ insufficient security, incentives to improve security are significantly weakened.
Conversely, if the bank is obliged to compensate clients for damages, it becomes interested in:

identifying suspicious transactions.
implementing real‑time monitoring systems.
developing anti‑fraud platforms.
improving authentication mechanisms.

It should be emphasised that a proper allocation of responsibility often has a greater impact on security than the adoption of new technologies.

Home Banking: A New Era of Threats

The development of internet banking radically changed the landscape of financial threats.
Whereas previously attackers needed physical proximity to a card or ATM, attacks could now be carried out remotely and on a mass scale.
The most common became:

Phishing

Fraudsters create fake bank websites or send emails, prompting users to disclose:

logins.
passwords.
one‑time confirmation codes.
payment card details.

Keyloggers

Malicious software can record:

keystrokes.
clipboard contents.
screenshots.
data entered into banking applications.

In many cases, attackers do not even need to break technical protection measures.
It is enough to convince the user to perform the required actions themselves.
That is why modern attacks are increasingly directed not against technologies, but against people.

Money Mules: The Industry of Financial Intermediaries

Another important problem is the so‑called money mules.
After successfully gaining access to bank accounts, criminals need to launder the stolen funds so that they cannot be directly linked to their identity.
For this, intermediaries are used.
A typical scheme looks like this:

New participants are recruited through fake job advertisements.
They are offered work related to payment processing.
Stolen funds are deposited into their accounts.
A portion of the amount is kept as a commission.
The remaining money is transferred further, often to other jurisdictions.

In many cases, such intermediaries are unaware that they are becoming part of a criminal scheme.
However, it is they who often face legal consequences:

freezing of bank accounts.
criminal prosecution.
obligation to compensate damages.

What Really Works in Banking Security

One of the most important conclusions of the article is that complicating authentication by itself rarely solves the fraud problem.
Even the most modern protection mechanisms can be bypassed through social engineering, implementation errors, or organisational weaknesses.
The following measures prove most effective:

continuous transaction monitoring.
anomaly detection systems.
rapid response to suspicious activity.
temporary blocking of risky operations.
effective funds recovery procedures.
quality auditing.
proper allocation of responsibility among system participants.

Main Conclusions

Banking systems demonstrate that security is a multidisciplinary task.
It includes:

cryptography.
accounting.
organisational procedures.
risk management.
economic incentives.
behavioural psychology of users.

The main lesson is:

Security is determined not by the strength of the strongest protective mechanism, but by the resilience of the entire system as a whole.

That is why effective protection of financial systems requires a combination of technical, organisational, and economic measures.
Cryptography plays an important role, but by itself it can never replace well‑designed processes, quality auditing, and proper distribution of responsibility.
Ultimately, banking security is not so much a task of protecting information, but rather a task of building a system in which fraud becomes difficult, costly, and economically unprofitable.

Audit and Reconciliation: The Unsung Heroes of Banking Security

When people talk about the security of banking systems, they usually think of cryptography, two‑factor authentication, or payment card protection. In reality, however, a significant portion of fraud is detected through much less visible mechanisms – audit and accounting reconciliation.
It is precisely these processes that make it possible to identify anomalies that cannot be prevented by technical means alone.

Reconciliation: The Foundation of Fraud Detection

Reconciliation is the process of comparing data from different sources to confirm their consistency.
The basic idea is simple:

If all transactions were executed correctly, the accounting records of the different systems should match.

In the banking sector, the following are regularly reconciled:

internal accounting accounts.
processing centre data.
ATM transaction logs.
correspondent bank accounts.
payment system reports.
cash balances in branches.

Any discrepancy requires investigation.
For example, if an ATM reports dispensing 100,000 euros, but the cassette accounting shows only a 90,000 euro decrease in cash, this is an obvious signal of possible fraud or a technical error.
It is precisely through reconciliation procedures that many financial crimes are discovered.
An important point should be emphasised:

In many cases, fraud is detected not by cryptographic mechanisms, but by a violation of the accounting balance.

This reflects a fundamental principle of banking security: it is impossible to hide actions that violate the financial integrity of the system for long.

Audit as an Independent Protection Mechanism

In many areas of information security, audit is viewed as a supporting tool. In the banking sector, its significance is much higher.
In effect, audit acts as one of the primary mechanisms for ensuring accountability.
An effective audit system must possess several key properties.

Independence

The persons performing operations must not check their own actions.
For example:

front‑office employees do not conduct internal investigations of their own transactions.
system administrators are not the sole custodians of event logs.
auditors are organisationally separated from operational units.

The absence of independence makes audit a formality and creates a favourable environment for abuse.

Immutability of Logs

Audit records must be protected against modification.
If an attacker can alter the history of their own actions, the value of the logs is completely lost.
Therefore, banking systems use:

cryptographic protection of logs.
integrity control systems.
storage of logs on independent platforms.
mechanisms to restrict administrative access.

Modern approaches to immutable logging and forensic readiness largely continue the ideas that were formed precisely in the banking industry.

Regularity of Checks

Checks must be performed continuously, not only after incidents.
This includes:

daily reconciliations.
spot checks of transactions.
analysis of suspicious transactions.
periodic external audits.

The faster a violation is detected, the smaller the potential damage.

Accountability

For each operation, it must be clear:

who performed the action.
when it was performed.
what data was changed.
on what basis the decision was made.

Accountability is one of the fundamental characteristics of a secure financial system.

The Four‑Eyes Principle

One of the best‑known banking control mechanisms is the Four‑Eyes Principle.
Its essence is that no critical operation should be performed and approved by a single person.
For example, separate approval may be required for:

large international transfers.
changes to transaction limits.
issuance of cryptographic keys.
granting privileged access.
approval of credit decisions.

This principle significantly reduces the risk of:

insider abuse.
accidental errors.
compromise of individual employees’ accounts.

Interestingly, banking practices have gradually spread far beyond the financial industry.
Today, similar mechanisms are applied in:

infrastructure change approval processes.
access management systems.
DevSecOps practices through mandatory code review.
critical change approval procedures.

Why Banks Bet on Detection Rather Than Prevention

Intuitively, it might seem that the main goal of security is to completely prevent attacks.
However, banking practice shows a different approach.
It should be noted:

Preventing all fraud is impossible.

The complexity of financial systems, the human factor, and the constant evolution of attack methods make absolute protection an unattainable goal.
Therefore, banks have historically shifted their focus to four areas:

Rapid detection of fraud.
Minimisation of financial damage.
Asset recovery.
Incident investigation.

This approach underlies the model:

Prevent → Detect → Respond → Recover

In effect, the banking industry arrived at modern security concepts long before they were formally articulated.
Many ideas actively used today have analogies precisely in banking practice:

Modern Concept	Banking Equivalent
Assume Breach	Assumption that some fraud is inevitable
Detection Engineering	Anti‑fraud systems and transaction monitoring
Zero Trust	Multi‑step transaction confirmation
Incident Response	Investigation and fund recovery procedures
Continuous Monitoring	Ongoing audit and reconciliation

Security as a Problem of Incentives

One of the most important conclusions of the article is the understanding that security is determined not only by technologies, but also by economic incentives.
People and organisations act rationally within the conditions created by the system.
If the system rewards transaction processing speed more than the quality of checks, employees will look for ways to bypass control procedures.
If the organisation does not bear the financial consequences of insufficient security, investment in security becomes less of a priority.
If users remain without legal protection, the level of fraud inevitably rises.
Therefore, when designing secure systems, it is necessary to consider not only technical aspects, but also issues of responsibility allocation.
Well‑designed incentives can improve security more effectively than the deployment of new protective technologies.

From Test Keys to Modern Authentication Mechanisms

The history of banking security shows that many modern ideas appeared long before the advent of computer cryptography.
Even in the era of telegraphic transfers, banks used special Test Keys to verify the authenticity of messages.
They were usually based on:

secret tables.
arithmetic algorithms.
code books.

The recipient of a transfer could verify the check value and ensure that the message had not been forged.
In essence, these mechanisms performed the same function as modern Message Authentication Codes (MAC):

confirmation of the sender’s authenticity.
message integrity control.
detection of unauthorised changes.

This demonstrates an important feature of the evolution of security:

Most fundamental principles appeared long before modern technologies. Only the methods of their implementation have changed.

Insiders vs. External Attackers

Public perception often associates banking threats exclusively with external hackers.
However, experience shows that a significant proportion of large financial losses are associated precisely with the actions of insiders.
Sources of risk may include:

bank employees.
payment system operators.
infrastructure administrators.
contractors.
processing centre staff.

The reason is that insiders already possess:

knowledge of internal processes.
legitimate access.
understanding of control procedures.
the ability to conceal traces of their actions.

That is why banking security places so much emphasis on:

separation of duties.
audit.
accountability.
independent control.

Final Conclusions

This article on banking and accounting demonstrates that ensuring the security of financial systems extends far beyond cryptography.
Effective protection is built on a combination of several interrelated elements:

maintaining data integrity.
strict accounting principles.
separation of duties.
independent audit.
continuous monitoring.
proper distribution of responsibility.
economic incentives that encourage secure behaviour.