Risk Management in Banking: How Are Credit, Fraud, AML and Payment System Risks Managed?

When we take out a bank loan, shop with a credit card or send money to another account, the transaction we see usually finishes in a few seconds. Behind the scenes, however, more than a money transfer or balance check takes place. Banks have to evaluate a wide range of financial and operational risks every day.

For example, when a customer makes an online purchase of TRY 20,000, we might think the bank only checks the card limit. In reality, card validity, security verification, fraud risk, transaction limits and various operational controls may also come into play.

Risk management in banking is not limited to card transactions. Lending to a customer, holding a foreign exchange position, managing deposits, deploying new software to production or purchasing an external technology service also fall within its scope.

In banking, completing a transaction technically is not enough for it to be successful. It must also be financially correct, secure, traceable and compliant with regulations.

In this article, we will examine banking risks through examples that could arise in real life. We will focus particularly on fraud, AML, chargebacks, operational resilience and risk assessment architectures that developers working in payment systems should understand.

Note: Customer names, transaction amounts, rates and risk scores in this article are illustrative examples created for educational purposes. They do not represent real banks' internal policies or decision thresholds.

1. What Is Risk Management in Banking?

Risk management is the identification, assessment, control and continuous monitoring of adverse events that may arise from a bank's activities.

An important point is that risk management does not aim to eliminate every risk.

A bank that stops lending entirely might reduce the possibility of credit losses. But it would also stop performing one of its core activities.

Similarly, a bank that rejects all high-value card transactions might prevent some fraud attempts. Yet it would also unnecessarily restrict legitimate customers' purchases.

This is why banks adopt an approach called Risk Appetite.

Risk appetite describes the level of risk a bank is prepared to accept in pursuit of its strategic objectives.

For example, a bank may:

• Limit credit concentration in certain sectors.
• Apply stricter controls to high-risk merchants.
• Set a low tolerance for outages in critical payment systems.
• Require additional customer verification for certain transactions.
• Maintain liquidity buffers against extraordinary economic conditions.

Risk management can essentially be considered in five stages:

Identify risk → Measure it → Control it → Monitor it → Report it

Consider a newly developed virtual POS application.

Before it goes live, the following questions need answers:

1. What happens if the same payment request is submitted twice?
2. How will the transaction be handled if the fraud service does not respond?
3. What happens if the application times out despite receiving a successful response from the bank?
4. How will a mismatch between end-of-day transaction records and bank records be detected?
5. Which data would be at risk if someone gained unauthorized access to the system?

Each question requires the assessment of a different risk.

2. Main Types of Risk in Banking

To understand banking risks, we first need to learn the main categories.

These types of risk are sometimes interconnected.

For example, a cyberattack may stop a bank's payment system. At first glance, this is a cybersecurity problem. However, its consequences can extend to operational losses, customer complaints, reputational damage and, under some circumstances, liquidity pressure.

Banking risks are therefore not treated as completely independent of one another.

3. Credit Risk: How Does a Bank Take on Risk When Lending?

Credit risk is the possibility that a bank will suffer a loss because a borrower fails to meet a financial obligation.

Let's examine a simple example.

Scenario: Ahmet wants to borrow TRY 500,000

Ahmet requests a personal loan of TRY 500,000 from the bank.

The factors the bank may evaluate include:

• The customer's income and expenses
• Existing loan debts
• Previous loan repayment performance
• Loan maturity and repayment schedule
• Available collateral
• Economic conditions
• The customer's overall indebtedness

Using this information, the bank assesses the risk that the loan will not be repaid.

There are three important concepts here.

3.1. PD — Probability of Default

PD is the probability that a borrower will default within a given period.

For example, suppose a customer's 12-month PD is estimated at 3%.

This means the model predicts a 3% probability of default for the customer during that period. It does not say the customer will definitely default.

3.2. LGD — Loss Given Default

LGD indicates how much of the bank's exposure is expected to be lost if the customer defaults.

Suppose the bank has a receivable of TRY 500,000.

After evaluating collateral, recovery opportunities and other factors, the bank might estimate a loss given default of 45%.

3.3. EAD — Exposure at Default

EAD refers to the amount the bank is exposed to at the time of default.

In our example, assume the exposure at default is TRY 500,000.

3.4. How is Expected Loss calculated?

A simplified expected loss calculation is:

Expected Loss = PD × LGD × EAD

In our example:

• PD = 3%
• LGD = 45%
• EAD = TRY 500,000

Calculation:

0.03 × 0.45 × 500,000 = TRY 6,750

Under these assumptions, the simplified expected credit loss for the relevant period is TRY 6,750.

However, this does not mean the bank will definitely lose TRY 6,750. It is a statistical estimate of expected loss. Actual provisioning, pricing and capital requirement calculations use more comprehensive methods.

3.5. What matters in practice?

The bank does not assess customers only individually; it also looks at the credit portfolio as a whole.

For example, if a very large share of the total loan portfolio consists of construction companies, a downturn in the sector may affect many customers simultaneously.

This is called Concentration Risk.

The bank may therefore set limits for customer, sector, country and other risk concentrations.

4. Market Risk and Liquidity Risk: Why Can a Bank Struggle Even When It Is Profitable?

Market and liquidity risks are among the reasons banks can experience serious problems despite appearing financially strong.

4.1. Market Risk

Market risk is the possibility that changes in interest rates, exchange rates and other market prices will adversely affect a bank's financial positions.

For example, suppose a bank purchases a bond at a particular interest rate.

When market interest rates rise, the market value of the fixed-rate bond may fall.

Similarly, a mismatch between foreign currency assets and liabilities can cause losses when exchange rates change.

Banks use position limits, scenario analysis, sensitivity measures and stress tests to manage these risks.

4.2. Liquidity Risk

Liquidity risk is the possibility that a bank will be unable to meet its financial obligations on time.

Consider an example.

A bank has substantial assets in long-term loans. However, many depositors want to withdraw their money within a short period.

The bank may have loan receivables it will collect in the future. But these receivables may not be immediately convertible into cash.

In this situation, the bank may experience a temporary or serious liquidity problem.

4.3. LCR and NSFR

Let's discuss two important indicators used to assess banks' liquidity risk.

LCR (Liquidity Coverage Ratio) measures a bank's high-quality liquid assets available to cover net cash outflows under a specified 30-day stress scenario.

A simplified example:

• High-quality liquid assets: TRY 120 million
• Net cash outflows during the 30-day stress period: TRY 100 million

LCR = 120 / 100 × 100 = 120%

The ratio is 120% in this example. Actual calculations take asset eligibility criteria, cash flow assumptions and regulatory rules into account.

NSFR (Net Stable Funding Ratio) assesses whether the bank has a stable funding structure over a longer horizon.

For a software developer, the important point is that these indicators require accurate, up-to-date data from many different systems.

An incorrect balance, missing data or faulty reporting is more than a technical problem: it can also lead to an incorrect assessment of the bank's risk position.

5. Operational Risk: How Does a Software Error Become a Financial Loss?

Operational risk is the risk of loss resulting from inadequate or failed internal processes, people, systems or external events.

It is one of the most tangible types of risk for developers.

Scenario: TRY 10,000 was transferred twice

Imagine Mehmet sending TRY 10,000 to another account through his banking application.

The normal flow is:

1. Mehmet creates a transfer request.
2. The bank's API system receives it.
3. The necessary limit and security checks are performed.
4. The money is transferred.
5. The result is sent to the mobile application.

However, suppose the transfer succeeds at step four, but the connection is lost at step five.

Because the mobile application does not receive the successful response, it may assume the transaction failed.

What happens if Mehmet presses the send button again?

Without the necessary controls, the system may execute the same transfer a second time.

This is where Idempotency comes in.

5.1. Why is Idempotency important?

Idempotency is an important design principle used to ensure that resubmitting the same logical request does not cause an additional financial transaction.

For example, a unique transaction key can be generated when a transfer is created.

In the first request:

• Transaction key: transfer-10001
• Amount: TRY 10,000
• Recipient: The account specified by Mehmet
• Status: Processing

When the system receives a second request with the same transaction key, it should check the previous transaction's status instead of sending money again.

However, generating a key alone is not enough.

A real system needs to persist the key, prevent requests with different payloads from using the same key, handle concurrent requests and store the transaction result correctly.

5.2. Why is Reconciliation necessary?

Suppose the application's database shows 1,000 successful transactions.

However, the financial records received from the bank or payment institution contain 999 transactions.

There is a discrepancy.

Reconciliation is the process of comparing financial records held in different systems to identify inconsistencies.

For example, the following information may be compared:

TX-1006 needs to be investigated.

The transaction may not actually have occurred, the bank record may be delayed, or the application may have incorrectly generated a successful status.

The correct approach is to verify the transaction's actual financial status before automatically executing it again.

In distributed payment systems, a request returning a successful response and a financial transaction actually occurring exactly once are not the same thing.

5.3. Other important engineering controls

The following technical approaches help reduce operational risk in banking systems:

• Audit Trail: Making transactions and important system changes traceable.
• Maker-Checker: Separating the people who prepare and approve critical operations.
• Role-Based Access Control: Ensuring users can perform only the operations they are authorized for.
• Circuit Breaker: Reducing the propagation of one service's failure to other services.
• Retry Policy: Managing repeated requests safely and in a controlled manner.
• Transactional Outbox: Reducing the risk of inconsistency between database transactions and message publishing.
• Disaster Recovery: Recovering systems after a major failure or disaster.

These controls complement one another; none should be considered sufficient on its own to provide complete financial security.

6. Fraud Risk: How Is a Card Transaction Determined to Be Risky?

Fraud is an attempt by a person or organization to obtain an unjust gain through intentional deception.

Stolen card use, account takeover, fraudulent merchant activity and similar methods are examples of fraud risk in card payment systems.

Let's work through a realistic e-commerce scenario.

Scenario: Ahmet makes a purchase of TRY 25,000

Suppose Ahmet purchases electronic goods worth TRY 25,000 from an e-commerce platform.

The transaction involves:

• Cardholder: Ahmet
• Issuer: Garanti BBVA
• Acquirer: İş Bankası
• Payment channel: E-commerce
• Transaction amount: TRY 25,000

The institution names in this example are used only to explain issuer and acquirer roles.

Depending on transaction routing and the infrastructure used by the parties, the following components may participate in a card payment:

Cardholder → Merchant → Payment infrastructure / Acquirer → Card network → Issuer

Fraud assessment can take place at different points in this flow.

The acquirer may assess the merchant and transaction, while the issuer may examine the cardholder's transaction behavior.

6.1. What data can a Fraud Engine examine?

For example, the following signals may be evaluated:

Transaction amount: Ahmet may normally spend TRY 500–2,000 and be spending TRY 25,000 for the first time.

Velocity checks: There may have been numerous payment attempts with the card over the last few minutes.

Device information: The purchase may originate from a device that has not been seen before.

Location and network signals: A network or geographic signal differing from previous behavior may attract attention.

Merchant history: The merchant may have previously experienced a high number of fraud reports or disputes.

Customer behavior: The transaction may differ significantly from the customer's past shopping habits.

However, using a new device or making a high-value purchase alone is not proof of fraud.

6.2. How does a Risk Score work?

A risk engine may produce a score by evaluating different signals.

For a purely illustrative example, let's use a risk score between 0 and 100.

These ranges do not represent any bank's actual decision rules.

In real systems, score interpretation depends on the model's structure, historical loss data, transaction type, risk appetite and applicable regulations.

Another important detail is that a risk score is not the same as the final authorization decision.

Even if a transaction passes fraud checks, the issuer may decline it for other reasons, such as insufficient available credit or card status.

6.3. Does 3D Secure eliminate fraud risk entirely?

No.

3D Secure provides security mechanisms for authenticating the cardholder in e-commerce transactions.

However, successful authentication does not mean the transaction is free from fraud under all circumstances.

For example, a fraudster may manipulate a customer into approving the transaction themselves.

Authentication, fraud analysis and card authorization are also different control processes.

These mechanisms should therefore complement one another in a secure payment infrastructure.

7. One of the Biggest Problems in Fraud Systems: False Positives

Fraud systems do not aim only to catch risky transactions.

Avoiding unnecessary blocks on legitimate customers' transactions also matters.

Two concepts arise here:

False Positive: A legitimate transaction is incorrectly flagged as risky.

False Negative: An actual fraudulent transaction is not detected by the system.

Let's build an example.

Assume a bank processes 10,000 card transactions in one day.

• 100 transactions are actually fraudulent.
• 9,900 transactions are legitimate.
• The fraud system detects 80 of the 100 fraudulent transactions.
• 2% of legitimate transactions are incorrectly flagged as risky.

The result:

The system's Recall is 80%.

However, only 80 of the 278 transactions flagged as risky are actually fraudulent, so Precision is approximately 28.8%.

In other words, not every risk alert from the system is correct.

Banks therefore need to assess more than the number of fraudulent transactions caught: false alarm rates, customer experience, financial losses and review costs matter too.

Not every incorrectly flagged transaction has to be declined. Some can be resolved through additional verification or manual review.

A good fraud system must manage the balance between security and customer experience.

8. Chargeback Risk: How Can an Approved Transaction Later Become a Loss?

An issuer's approval of a card transaction does not mean it can never be disputed in the future.

A chargeback involves a cardholder disputing a transaction for certain reasons and the initiation of a financial adjustment process under the relevant card network rules.

Scenario: A customer makes a TRY 15,000 purchase and disputes it

Imagine Mehmet purchasing a phone worth TRY 15,000 from an e-commerce website.

The payment succeeds and the seller ships the product.

A few days later, Mehmet contacts his bank and reports that he did not make the transaction.

A dispute process may then be conducted based on the transaction history and relevant card network rules.

The following information may be important for the merchant or acquirer:

• Order date and amount
• Transaction reference number
• Authentication results where appropriate
• Order and invoice information
• Delivery documents
• Correspondence with the customer
• Other available technical transaction records

This information is assessed according to the nature of the dispute and the relevant card network rules.

For example, delivery of the product may be important evidence for some dispute types. However, it is not sufficient on its own for every dispute.

Similarly, using 3D Secure does not automatically eliminate all chargeback types.

8.1. The software side of chargeback risk

An important software requirement emerges here.

Imagine an e-commerce platform that can quickly find all relevant records for a particular card transaction among millions of transactions.

A well-designed system:

1. Identifies the disputed transaction.
2. Links order and payment records.
3. Makes the necessary evidence available to authorized people.
4. Manages the document workflow appropriate to the dispute type.
5. Tracks deadlines and case statuses.
6. Matches resolved cases with financial records.

Reliable data linking, document integrity, access control and traceability play important roles in this architecture.

A chargeback is not only a financial operation; it is also a significant data and process management problem.

9. Merchant Risk: The Cardholder Is Not Always the Source of Risk

Risk assessment in card payment systems does not focus solely on the cardholder.

Merchants can also be an important source of risk on the acquiring side.

Scenario: A new e-commerce store

Suppose a newly established e-commerce company wants a virtual POS service.

The company processes low-value transactions in its first weeks.

After a while, transaction volume suddenly increases and many high-value sales occur.

This is not necessarily a negative event. A successful advertising campaign or a new product launch may have increased transaction volume.

However, the following risk management questions may arise:

• What is the company's actual business activity?
• Are the products sold and transaction amounts consistent with its business model?
• Are delivery times normal?
• How are refund and chargeback rates changing?
• Can the company meet its financial obligations?
• Are transactions concentrated on particular cards or devices?

For example, if the company collects substantial payments but cannot deliver the products, refund and dispute obligations may arise.

Depending on the agreement and applicable rules, the acquirer may use transaction monitoring, limits, collateral, reserves or other controls for these risks.

Merchant Risk Management is therefore an important specialist field for payment institutions and banks that acquire merchants.

10. What Is AML? How Does It Differ from Fraud?

AML (Anti-Money Laundering) covers policies, controls and processes intended to prevent the laundering of criminal proceeds.

Fraud and AML may be related, but they do not focus on the same problem.

Fraud focuses on preventing and detecting fraudulent activities, while AML focuses on preventing the financial system from being used for laundering criminal proceeds and related financial crimes.

Scenario: Unusual money movements through an account

Imagine many transfers from different people arriving in a newly opened bank account within a short period.

Suppose most of these amounts are transferred to other accounts shortly afterward.

When considered alongside the customer's economic profile and purpose for using the account, this transaction pattern may require review.

However, this behavior alone does not mean a crime has been committed.

For example, a business receiving payments from many customers and regularly transferring money to suppliers may be carrying out entirely legitimate commercial activity.

The customer profile and economic purpose of transactions are therefore important in AML controls.

10.1. KYC — Know Your Customer

KYC refers to processes for understanding and identifying the customer.

Verifying identity information, understanding the customer's activities, identifying the beneficial owner and establishing monitoring appropriate to the risk profile are parts of this approach.

KYB (Know Your Business) processes also play an important role for corporate customers.

10.2. Transaction Monitoring

Transaction Monitoring means monitoring customer transactions using specified rules and analytical mechanisms.

Example checks include:

• Transaction volumes inconsistent with the customer profile
• Transfer patterns with no explainable economic purpose
• Suspicious movements between connected accounts
• Unusual transaction frequency
• Transaction relationships carrying high-risk indicators

One of the most important principles in AML control is that decisions should not be based solely on transaction amounts.

Türkiye's MASAK regulations state that suspicious transactions must be reported regardless of amount.

10.3. Do AML systems automatically determine criminal guilt?

No.

An AML system may detect a suspicious pattern and generate an alert.

That alert does not establish that the person conducting the transaction is guilty of a crime.

The necessary review and assessment processes are applied; obligations such as suspicious transaction reporting are fulfilled by authorized people under the relevant legislation.

This distinction must also be maintained when designing AI-assisted AML systems.

11. Cyber Risk: Why Does Information Security Have Particular Importance in Banking?

Protecting data and cryptographic keys used in banking infrastructure is critical.

Consider a payment system.

It may have access to sensitive information such as card details, customer accounts, transaction histories and financial messages.

An attacker gaining unauthorized access to this information can cause financial loss and service disruption as well as a data breach.

The following principles are therefore important in banking software:

Least Privilege: Users and system components should receive only the permissions they need.

Segregation of Duties: Permissions and responsibilities for critical operations should be appropriately separated.

Encryption: Sensitive data should be protected with cryptographic methods appropriate to the use case.

Key Management: The lifecycle of cryptographic keys should be managed securely.

Audit Logging: Critical activities should be traceable, and logs should be protected against unauthorized modification.

Vulnerability Management: Vulnerabilities should be identified regularly and addressed according to their risk.

11.1. Why is an HSM used?

An HSM (Hardware Security Module) is a hardware-based security component used to manage sensitive cryptographic keys securely and perform certain cryptographic operations in a protected environment.

In card payment systems, HSMs can be used for activities such as PIN operations and verification of certain card cryptograms.

However, using an HSM does not eliminate all security risks.

If the application's authorization controls are faulty or the services accessing the HSM are not designed securely, the system can still carry risk.

11.2. Why is PCI DSS important?

PCI DSS (Payment Card Industry Data Security Standard) is an industry standard for the security of environments where card data is processed, stored or transmitted.

It includes requirements particularly in areas such as protecting card data, secure access, system monitoring and regular security assessments.

For example, a developer logging sensitive card authentication data for debugging can create a serious security and compliance problem.

Which systems may contain card data, how it will be protected and which information must not be stored should be considered at the beginning of system design.

12. Model Risk: What Happens If an AI Decision Is Wrong?

The use of artificial intelligence and machine learning in banking adds a new dimension to risk management.

Predictive models can be used in areas such as Fraud Detection, credit scoring, transaction monitoring and operational anomaly detection.

However, these models can also make mistakes.

Scenario: A fraud model loses performance

Suppose a bank trains a machine learning model on historical transactions.

Imagine the model performs well during its first months.

Over time, however, customers' shopping behavior changes. New payment methods appear and fraud patterns evolve.

Success on historical data does not guarantee that the model will maintain the same performance in the future.

This problem can be approached in terms of Model Drift.

12.1. Model Drift

Model drift relates to changes in data distributions or in relationships between data and the target that affect model performance.

For example, purchases above a certain amount may once have been rare, but inflation and changing customer behavior may make those amounts common over time.

If the model is not updated, unnecessary fraud alerts may increase.

12.2. Explainability

When a model assesses a transaction as risky, it is important to explain at an appropriate level which factors influenced that decision.

For example:

• Does the transaction differ significantly from the customer's behavior?
• Have many failed attempts occurred in a short time?
• Are there historical risk signals associated with the merchant?
• Is the data being used incomplete or outdated?

Explainability supports both model performance evaluation and human review when necessary.

12.3. Human-in-the-Loop

Making all decisions automatically may not be appropriate for every scenario.

Some transactions can be resolved directly, while more complex or high-impact cases can be referred for expert review.

Where human review is necessary should depend on the decision's impact, regulations, model reliability and the institution's control policies.

12.4. Model Governance

Developing a model alone is not enough for a bank.

The data it was trained on, the version running in production, how it was validated and how its performance is monitored also matter.

A sound model governance approach should answer these questions:

• Who owns the model?
• Which datasets were used?
• Was the model independently validated?
• How will performance degradation be detected?
• How will incorrect decisions be reviewed?
• How will upgrades and rollbacks be managed?
• Can decisions be audited afterward?

Particularly in systems affecting financial decisions, model traceability can become at least as important as predictive performance.

13. How Can a Real Risk Engine Be Designed?

Let's now approach the subject from a software architecture perspective.

Imagine a payment institution or bank wanting to develop a Risk Engine to assess card transactions.

All controls do not have to be collected in a single service.

An architecture can consist of components with different responsibilities.

13.1. Transaction Gateway

This is the component through which transactions enter the system.

Basic request validation, transaction references and routing information can be handled at this layer.

For example, an incoming transaction may be represented by these fields:

These fields form an illustrative data structure for educational purposes.

In real systems, the scope, processing and protection of card information must be designed in accordance with the relevant standards.

13.2. Feature Collection

This is the layer where data used in risk assessment is collected.

For example:

• Number of transactions in the last 10 minutes
• Distribution of previous transaction amounts
• Merchant risk indicators
• Device history
• Previous security verification results

This data must be current, consistent and accurate.

A strong model alone is not enough. Incorrect or delayed data may prevent correct decisions.

13.3. Rule Engine

The Rule Engine evaluates predefined business rules.

For example, a rule may require an additional check if a certain number of failed attempts is detected for a transaction.

Rules may operate at different levels:

• Transaction level
• Card level
• Customer level
• Merchant level
• Device level

Versioning rules and making changes auditable are important.

13.4. Machine Learning Model

The Machine Learning component can produce predictions about transactions based on patterns learned from historical data.

The important point is that the score produced by the model is not always the final decision itself.

The decision mechanism may evaluate the model score together with rule results and other controls.

13.5. Decision Engine

The Decision Engine interprets risk assessment outputs according to transaction policies.

Example decisions include:

• Route the transaction through the normal flow
• Request additional verification
• Decline the transaction
• Refer it for review

These decisions may vary depending on the system's role and the transaction stage.

For example, an acquiring-side blocking decision and an authorization decline issued by the issuer are not the same technical or operational action.

13.6. Audit and Case Management

The risk engine's decisions should be reviewable afterward.

For example, if a customer asks why a transaction was declined, authorized personnel should be able to assess it using appropriate records.

The following information may therefore be retained for a transaction:

• Transaction reference
• Decision time
• Versions of the rules applied
• Model version
• Risk assessment result at an appropriate level of detail
• Source of the final decision
• Manual review history, if any

When determining the scope of records, data minimization, personal data protection, access permissions and retention obligations should be considered.

13.7. What happens if the fraud service does not respond?

This is one of the most important questions to answer before operating in production.

Unconditionally approving all transactions when the risk engine is unavailable, or unconditionally declining every transaction, can both have serious consequences.

The organization should have a predefined failure-handling policy based on transaction type and risk level.

For example, some transactions can be safely declined, some routed to additional controls and others assessed by alternative systems under certain conditions.

The aim is more than maintaining service continuity.

Which risks will be accepted and which will be blocked during a system failure must be defined in advance.

14. Which Metrics Should Be Monitored for a Risk Engine?

When developing a risk system, looking only at API response time is not enough.

Its business outcomes must also be measured.

Some of these metrics reflect financial performance, some reflect security and model effectiveness, and others reflect technical service quality.

For example, a rising fraud detection rate may appear positive. However, if many legitimate transactions are blocked at the same time, the overall effect may be less favorable than expected.

Similarly, low API latency is a positive technical indicator, but a fast system producing incorrect financial outcomes cannot be considered successful.

15. Third-Party Risk: Is an External Fraud Service Enough?

Today, banks do not have to develop every technical component internally.

External service providers can be used for fraud analysis, identity verification, cloud infrastructure, data analytics and other areas.

However, purchasing an external solution does not mean the associated risk has been transferred entirely to the service provider.

For example, suppose a bank integrates with two different fraud services.

It still needs to answer these questions:

1. What happens if one service becomes unavailable?
2. How is a decision made if the two systems produce different results?
3. Which customer data is transferred to external systems?
4. Are the providers' security and access controls adequate?
5. Can the risk decisions produced be audited?
6. How is service performance measured over time?
7. How will the process continue if the relationship with a provider ends?

Using multiple services may reduce some risks; however, dependence on the same data, infrastructure or model across services can create new concentration risks.

The Basel Committee on Banking Supervision's principles for third-party risk management, published in December 2025, specifically address financial institutions' growing dependence on external service providers.

Even when an external fraud system is used, the organization's own risk policies, oversight mechanisms and business continuity controls therefore remain important.

16. Regulations Affecting Risk Management in Türkiye

Developing technical solutions for banking and payment systems requires an understanding of the regulatory framework.

The following institutions and standards are particularly important in Türkiye.

BDDK

The Banking Regulation and Supervision Agency carries out regulatory and supervisory activities for the banking sector.

Areas such as banks' internal systems, information systems, risk management and capital adequacy are associated with BDDK regulations.

Information systems, electronic banking and audit requirements are particularly important for software teams.

TCMB

The Central Bank of the Republic of Türkiye has important responsibilities in regulating and overseeing payment systems and the activities of payment and electronic money institutions.

Law No. 6493 and related secondary regulations form the main legal framework for payment services.

MASAK

The Financial Crimes Investigation Board is important in relation to obligations for combating money laundering and terrorist financing.

Customer due diligence, suspicious transaction reporting and risk-based control processes are considered within this framework.

Basel Standards

International standards developed by the Basel Committee on Banking Supervision provide important references for capital, liquidity, risk management and operational resilience in banking.

PCI DSS

PCI DSS is an industry security standard for protecting payment card data.

It is not a regulatory institution and should not be treated as a control framework that replaces all banking risk management.

NIST AI Risk Management Framework

This is a voluntary framework developed to manage the risks of artificial intelligence systems.

It is a useful reference for trustworthiness, measurement, monitoring and governance in AI applications affecting financial decisions.

Which of these frameworks are directly binding should be assessed according to the institution's activity, applicable legislation and scope of the application.

17. Lessons Software Developers Should Take from Risk Management

Developing banking software requires thinking beyond conventional application development.

For example, an order list loading a few seconds late in an e-commerce application is usually a performance problem.

But in a financial system, executing the same transfer twice or recording a failed transaction as successful can have direct financial consequences.

This is why I consider it important to ask certain questions during the design stage of financial software.

How do we know the transaction actually succeeded?

Is receiving an HTTP 200 response sufficient on its own? Does the external system's result match the local database state?

What happens if the same transaction is submitted again?

Have transaction references and idempotency mechanisms been designed correctly?

Are the records consistent with one another?

How will missing or extra transactions be detected during end-of-day reconciliation?

Does the system behave safely when it fails?

Is it clear what happens when the fraud service, database or messaging infrastructure becomes unavailable?

Who can access the data?

Are financial records, customer information and critical configurations protected by appropriate authorization controls?

Can we explain decisions afterward?

Are the necessary audit trails available when a transaction is declined, a risk rule changes or a model version is updated?

Is the system monitored only from a technical perspective?

Beyond CPU, memory and API latency, are financial inconsistencies, fraud losses and incorrect decisions also tracked?

The answers to these questions directly affect software architecture.

18. The Future of Risk Management in Banking: Data, AI and Resilience

As transaction volumes in banking systems grow, the amount of data used in risk assessment and the dependencies between systems also increase.

Traditional rule-based controls remain important, while machine learning and data analytics can be used to assess more complex patterns.

However, there is an important problem here.

More data and more complex models do not automatically mean better risk management.

A model trained on incorrect data can systematically produce incorrect decisions.

A powerful risk engine may fail to prevent financial inconsistencies if the payment system it connects to is poorly designed.

Even a highly available service cannot be considered secure if critical access permissions are managed incorrectly.

I therefore believe three areas need to develop together in the future of banking risk management:

Data quality and governance: Reliable, current and traceable data for risk decisions.

Intelligent decision systems: Mechanisms combining rule engines, statistical models and human review where necessary.

Operational resilience: Infrastructure capable of continuing critical financial operations in a controlled manner during attacks, errors or external service outages.

The Basel Committee's BCBS 239 principles also emphasize the importance of banks being able to aggregate risk data accurately, completely and promptly.

This can be considered a matter of risk governance as well as data engineering.

Conclusion

Risk management in banking covers a much broader field than detecting fraudulent transactions or evaluating loan applications.

Credit risk, market risk, liquidity risk, operational risk, fraud, AML, cybersecurity and model risk must be managed in an interconnected way.

From a payment systems perspective, many of these risks may appear within the same transaction flow.

A card transaction may be securely authenticated but declined because of insufficient available credit. Another may technically succeed yet create a discrepancy during end-of-day reconciliation. A third may become subject to a chargeback weeks after approval.

These examples illustrate an important reality for software engineering:

Writing correct code in financial systems means more than developing a functional application; it means anticipating potential risks and designing secure, consistent, auditable and resilient systems.

For developers interested in banking and payment technologies, risk management is not a distant subject belonging only to finance teams.

Many technical decisions, from APIs to data models and from transaction records to AI algorithms, are part of risk management.

This is why I believe a developer working in banking should understand not only how transactions occur, but also when things can go wrong and how those situations should be managed.

This content is intended for technical information purposes. It does not constitute legal, financial or regulatory compliance advice. As legislation and technical standards may change over time, current official texts should be checked before implementation.