top of page

Turkish Bank - Fraud Use Cases

  • Writer: Pavan Raja
    Pavan Raja
  • Apr 9
  • 4 min read

Summary:

This document outlines a system for detecting and preventing financial fraud using HP ArcSight technology within Turkey's banking sector. The process involves creating dynamic active lists such as SafeDestinationAccountsList, SuspiciousEventsList, LastTransferList, CumulativeAmounList, and CustomerEFTProfile to monitor suspicious activities. Rules are implemented to query data from databases like FRD.FRAUDTRANSACTIONS and FRD.FRDTRANSACTIONDETAILS, extracting information for fraud detection. Additional features include executing commands like stopping transfers for confirmation, creating console logs, and initiating IVN calls based on specific conditions related to safe destinations, suspicious activities, and transaction volumes. The system also includes a main console where agents monitor and annotate alarms before taking manual actions to release or cancel transactions.

Details:

The article discusses financial fraud detection and prevention using HP ArcSight, particularly within the context of Turkey's financial landscape. It highlights several key points about fraudulent activities there: 1. **Prevalence**: Financial fraud incidents are on the rise globally, primarily due to factors such as an increasing number of potential victims, easier access to tools and techniques for fraudsters, direct cash theft leading to less physical intrusion, and lower risks of arrest in many cases. Turkey is no exception, with a growing trend of fraudulent activities. 2. **Detection Techniques**: The article outlines a process involving the use of ArcSight technology to detect suspicious financial transactions. Initial assessments involve confirming or questioning transactions based on predefined criteria like money transfers and login activity. This includes making IVN (Interactive Voice Notification) calls to verify if customers are aware of such activities, which can help in identifying fraudulent scenarios more effectively. 3. **Rule Creation**: For effective fraud detection, rules are created that filter events for monitoring or rule application based on specific conditions. Filters reduce the complexity and workload on the system by allowing pre-defined criteria to be applied across multiple rules. However, this also introduces a potential load on the rule engine which might affect performance efficiency. 4. **Automation and Manual Actions**: Commands such as canceling transactions or releasing holds can be executed manually through integration commands or automatically through rule actions once specific conditions are met. Automated actions often involve scripts that interact with web services to perform tasks like sending SMS notifications or making IVN calls for confirmation. 5. **Black/White Lists**: Static lists for black and white-listing are created for general use, including IP addresses, customer IDs, account numbers, etc., which can be applied in the conditions of most rules to provide a baseline for comparison against incoming data. These lists help in distinguishing normal from suspicious activities more efficiently. 6. **Data Collection**: Logs are collected from both core banking systems and each channel’s database using ID Based Flex Connectors, providing detailed demographic information and specific details related to the transactions that might not be available elsewhere. This multi-source data collection enhances the depth of analysis for fraud detection. In summary, this article provides a comprehensive guide on how financial institutions can leverage advanced technology like HP ArcSight to detect and prevent fraud in banking systems, with a particular focus on Turkey’s unique challenges and potential solutions. This document outlines a system for financial fraud detection and prevention, focusing on the creation of dynamic active lists to monitor suspicious activities. The system involves querying data from databases such as FRD.FRAUDTRANSACTIONS and FRD.FRDTRANSACTIONDETAILS, extracting information like CUSTOMERID, CUSTOMERNAME, IP, AMOUNT, TRANSACTIONORSERVICE, ACCOUNTOPENINGDATE, and others. The process includes several steps for preparing dynamic active lists: 1. **SafeDestinationAccountsList**: This list identifies safe destination accounts for each customer based on money transfers made by them. Rules are implemented to write customer IDs and destination account numbers over a specific amount into a temporary list with a TTL (Time To Live) value of X days, then transferring this data to the main SafeDestinationAccountsList which has a longer TTL. 2. **SuspiciousEventsList**: This list captures details of suspicious activities that might indicate fraudulent behavior. A rule is created to detect and record customer IDs and names of suspicious events with various TTL values depending on the severity. 3. **LastTransferList**: This list stores detailed information about the last money transfer for each customer, enabling future rules to utilize this historical data. It also allows tracking cumulative amounts if needed. 4. **CumulativeAmounList**: Tracks the cumulative amount of money transfers over the last X hours per customer to monitor transaction volumes. 5. **CustomerEFTProfile**: This list profiles money transfer patterns for customers over the past 90 days, assessing them against predefined thresholds for maximum or average amounts. Additional features include using variables in profiling rules and executing commands such as stopping transfers for confirmation, creating console logs, and initiating IVN calls based on specific conditions related to safe destinations, suspicious activities, and transaction volumes. The system also includes a main console where agents monitor and annotate alarms before taking manual actions to either release or cancel transactions. The roadmap within the document seems to be focused more broadly on internal fraud risk determination, specifically mentioning employee risk groups like those with credit card debt or who have received loans. This suggests that while the primary focus is clearly on financial fraud detection through digital systems and rules, there's also an implication for broader corporate governance in managing risks associated with certain types of employees. This document outlines a comprehensive approach to detecting and preventing financial fraud within Finansbank by monitoring various aspects of customer transactions and interactions with employees. Key strategies include: 1. **Monitoring Critical Transactions**: Observing changes in OTP phone numbers and suspicious money transfers made by specific employees involving the same customers. 2. **Taking Immediate Action**: Blocking further money transfers, loan disbursements from the customer, or taking any other financial actions deemed necessary based on observed fraud patterns. 3. **Integration with Credit Card Fraud System**: Notifying of potentially fraudulent credit card usage and following up on suspicious transactions to protect both the bank and the cardholder. 4. **Call Center Monitoring**: Keeping a close eye on transactions made using suspicious cards in the call center environment, ensuring immediate action is taken if necessary. 5. **Blocking Additional Transactions**: After identifying potential fraud, blocking further financial actions such as money transfers or loan applications by the customer. By implementing these measures, Finansbank aims to enhance security and prevent fraudulent activities, safeguarding both its customers' funds and the bank's reputation.

Disclaimer:
The content in this post is for informational and educational purposes only. It may reference technologies, configurations, or products that are outdated or no longer supported. If there are any comments or feedback, kindly leave a message and will be responded.

Recent Posts

See All
Zeus Bot Use Case

Summary: "Zeus Bot Version 5.0" is a document detailing ArcSight's enhancements to its Zeus botnet detection capabilities within the...

 
 
 
Windows Unified Connector

Summary: The document "iServe_Demo_System_Usage_for_HP_ESP_Canada_Solution_Architects_v1.1" outlines specific deployment guidelines for...

 
 
 

Comments


@2021 Copyrights reserved.

bottom of page