In the rapidly evolving world of customer-facing businesses, providing an exceptional omnichannel customer experience has become the key to success. As online retail sales have soared over the last decade, it has become evident that connecting data across various silos is essential for a true omnichannel approach. In this blog post, we will explore how TigerGraph, a powerful graph database platform, is helping large customer-facing businesses create a connected customer platform, enabling them to leverage data effectively, improve customer interactions, and boost profits.

The Challenge of Consolidating Customer Data

Creating a comprehensive and coherent dataset that integrates everything known about customers, their purchasing behavior, and service usage is the foundation of a connected customer platform. However, consolidating these datasets is often a daunting task, and many businesses have struggled to achieve it successfully.

Retailers often face the challenge of dealing with messy customer data, multiple accounts for a single customer, and inconsistencies when they have grown through acquisitions. Moreover, purchase decisions are made at the customer or household level, but the data is often at a device or account level, leading to potential inaccuracies in models and insights.

The Power of Graph Databases

While traditional databases have failed to effectively connect data across silos, graph databases have emerged as a game-changer. Unlike traditional tabular databases, graph databases work on networks of connected data, allowing businesses to structure their databases as vast networks of customer-related information.

Graph databases offer several advantages in consolidating data, including:

• Flexibility: Graphs don’t impose a single structure on all records, enabling connections between data from different silos, even with inconsistent structures and many-to-many relationships.
• Graph Entity Resolution: Using this technique, the graph can quickly identify likely matches between data from different systems, resolving them through fuzzy matching, address standardization, and machine learning.

TigerGraph: Transforming Customer Data and Driving Omnichannel Profits

TigerGraph has emerged as a leading graph database platform, delivering unparalleled performance and scalability. Its ability to handle real-life retail and banking datasets up to 30 times larger than its closest competitor and its remarkable speed, up to 1000 times faster, make it a perfect fit for large customer-facing businesses. A case in point of successful utilization of TigerGraph is demonstrated by these two enterprises, showcasing how they have effectively leveraged its capabilities.

1. Multichannel Retailer: By leveraging TigerGraph, a large multichannel retailer was able to bring together data from five legacy acquisitions and connect family units of customers using multiple devices, payment cards, and addresses. This allowed them to market consistently across all customer touch points and resulted in a 17% increase in customer engagement.
2. Global Media Conglomerate: Another success story involves a global multichannel media conglomerate that merged data from 15 independent divisions to create the first and largest identity graph in the advertising industry. This enabled them to target audiences with personalized commercials aligned with their interests, leading to improved advertising performance.

The importance of a connected customer platform cannot be underestimated in today’s customer-centric business landscape. TigerGraph is empowering large customer-facing businesses to consolidate data across silos, improve customer interactions, and drive omnichannel profits. As the platform continues to gain recognition and accolades, it remains a valuable asset for businesses seeking to deliver a true omnichannel customer experience.

If you’re interested in exploring how TigerGraph can transform your customer data and drive profits in your business, you can sign up for a free instance of TigerGraph Cloud at tgcloud.io or contact us at info@tigergraph.abstage.xyz.

Bank fraud is a serious concern that affects financial institutions and their customers worldwide. Large organized criminal groups are often the primary perpetrators of fraud, and understanding their tactics is crucial for effective detection and prevention. In this blog post, we will provide a clear and concise overview of bank fraud, its distinctiveness from anti-money laundering (AML), the two main types of fraud (loan and credit card fraud), and how TigerGraph’s detection methods contribute to combating fraud.

Fraud vs. AML: Fraud and AML may appear similar from a data and analytics perspective, but they have distinct commercial implications and are dealt with separately within banks. Fraud involves criminals misrepresenting their identity to steal money from the bank or its customers, primarily resulting in financial losses. AML, on the other hand, focuses on monitoring and reporting money movement to prevent criminals from hiding illicit funds, with non-compliance potentially leading to fines for banks.

Two Types of Fraud: Loans and Credit Cards: Fraud within the banking sector can be broadly categorized into two main types: loan fraud and credit card fraud. Loan fraud typically involves criminals setting up accounts, engaging in legitimate transactions until their credit rating allows them to borrow money, and subsequently absconding with the borrowed funds. Credit card fraud, on the other hand, encompasses criminals either applying for or taking over someone else’s card to withdraw cash or make purchases that can be resold for cash. In both cases, the intention not to repay the borrowed funds or settle the card charges constitutes the fraudulent act.

Detecting Fraud: There are two critical points at which fraud detection becomes crucial: during the application process and at the time of the fraud itself. Detecting suspicious accounts during the application stage involves assessing whether the provided information aligns with known patterns and connections to other suspicious accounts. Detection at the time of the fraud relies on identifying abnormal transaction patterns within the account, often in conjunction with changes in behavior observed in connected accounts.

Detection and Investigation: Fraud detection teams primarily focus on two activities: detection and investigation. Detection aims to identify suspicious accounts and activity through automated means, often utilizing machine learning algorithms. The challenge lies in striking a balance between detecting as much fraud as possible while minimizing false positives and not mistakenly flagging genuine customers as fraudsters. Investigation, on the other hand, involves confirming whether a suspicious account is indeed involved in fraudulent activities. This step typically requires human intervention by trained fraud investigators and can be resource-intensive due to the complexity and volume of transactions associated with fraudulent accounts.

TigerGraph’s Contribution to Fraud Detection: TigerGraph, a leading provider of fraud detection solutions, employs various methods to detect and combat bank fraud effectively. One crucial step is consolidating information to establish connections between accounts and transactions, enabling the identification of suspicious individuals and groups. TigerGraph leverages advanced techniques such as Shortest Path, (Personalized) Page Rank, Louvain Community, and Weakly Connected Components to assess the proximity of an account to known suspicious accounts, determine its centrality in a network, and identify connections to suspicious groups.

Additionally, TigerGraph’s behavioral analysis focuses on monitoring changes in account activity in real-time, both for the account in question and its closely connected accounts. By analyzing transactional behavior and detecting significant changes, TigerGraph’s system can flag potentially fraudulent activities promptly.

Conclusion: Understanding bank fraud is crucial for financial institutions to protect themselves and their customers from significant financial losses. Distinguishing fraud from AML, recognizing the two main types of fraud (loan and credit card), and comprehending the crucial points of detection can aid in implementing effective countermeasures. With its advanced detection methods and focus on consolidating information and analyzing behavior, TigerGraph contributes to the fight against bank fraud, offering financial institutions the tools they need to detect and prevent fraudulent activities in a timely and cost-effective manner.

For more questions, and to connect to our team, please contact us at info@tigergraph.abstage.xyz. 

Figure 1: AML generic workflow.

Financial accounts are linked to many transactions. Alert entities are suspicious accounts that are presented to fraud analysts, who can further put alert entities into a case study container.

Introduction

In the world of finance, preventing money laundering is of paramount importance. This blog aims to provide insights into how financial institutions implement Anti-Money Laundering (AML) practices using graph databases. By examining the relationship between commercial accounts, consumer accounts, and their associated financial transactions, we can better understand the steps involved in combating money laundering.

We also observe that although AML software is subject to compliance regulations, its impact on the financial institutions’ overall revenue may not be direct. However, it is worth mentioning that the same techniques and frameworks employed in AML software can be effectively utilized to identify instances of fraud and minimize the number of false positives encountered by fraud analysts. This, in turn, alleviates the workload on analysts and leads to significant operational cost savings for financial institutions.

Accounts and Transactions

Financial institutions serve both commercial and consumer customers, each having their respective accounts (blue node). These accounts are linked to numerous financial transactions (green node), including deposits, withdrawals, money transfers, and more. By analyzing these transactions, institutions can identify suspicious activities indicative of money laundering.

Steps to Combat Money Laundering

1.Run an entity resolution algorithm on all accounts based on common address, common phone, common ssn etc. to detect identical or similar accounts and merge them into one entity.

Note: This step is easy in TigerGraph GSQL, but not easy by relational database or Neo4j Cypher.  This is a graph clustering algorithm problem, GSQL’s accumulator makes it easy. 

2. After grouping all accounts, the transactions of each account group will be used to generate single alerts (pink node). Each alert means some rules are violated. Common rules are:

• Does the account have a transaction that has been marked as fraudulent?
• Does the account reside in a group whose group size is 100 or above? Looks like a non-human natural setup!
• Does the account have international wire transfer (inbound or outbound) passing a threshold? Red flag!

Note: This is a 1-hop aggregate query, it check each account’s transactions, and insert into the graph a “single alert” node, and connect the newly created node with the account node. GSQL supports insertion of nodes and edges.

3. Based on the generated alerts, risk scores are calculated for each account group. These risk scores provide an overall indication of the associated risk level. If an account group’s risk score exceeds a predefined threshold, an “Alert Entity” node is created. Such entities are subjected to thorough scrutiny by alert analysts. Alert analysts can further create a “case” node to group a set of related alert entities.

Note: This is a 1-hop aggregate query, it check and aggregate each account’s single alerts, and insert into the graph “Alert entity” node, and connect the newly created node with the account node. GSQL supports insertion of node and edges.  

4. Case analysts can further examine the case for further fraud study.

Why Graph Database

Entity resolution is easier. Fraudulent users have finite physical resources– IP, device, residential address, SSN etc. By grouping accounts based on those finite resources, we can find suspicious account groups that are artificially manipulated by fraudsters. Graph database can naturally run a weakly connected component algorithm or other unsupervised cluster algorithms to find such account groups, which is hard in relational database.

Avoid ad hoc joins. Graph storage format is just a better way to manage data. Why? Essentially, unlike relational databases which do runtime join to connect table rows at a per query basis, graph database obviate the runtime join for all queries. Instead, graph database materialize all joins at loading time. When you finish the initial data ingestion, or you do incremental data ingestion, each insertion materialize a relationship. At runtime, you just traverse the edge (relationship) for a source to a target, you never need to do a join for two vertices that you know they have a relationship. For example, in step 2 above, if you use a graph database, you just aggregate all transactions following the edges from the transactions to their linked accounts. But in relational databases, you need to join the transaction table with the account table to achieve this. In step 3 and 4 above, when alert entity or case are presented to the fraud analysts, they will double click the alert entity or the case, which brings them to a graph (network) exploration panel, the alert entity’s 1-hop neighborhood will be unfold on the screen (no join for graph database here, but will trigger a runtime join for relational database query engine), and the analysts can continue her ad hoc double click to investigate the traces of the alert entity, 3-hop, 4-hop etc., all have not join cost for graph database, but a join cost for relational database. In other words, graph database storage is just smarter, in that it can avoid repetitive runtime joins by materializing joins as edges. It is just greener for the planet.

Why TigerGraph

Scalability: transactions are large, can be 500G to 10T. TigerGaph has been proven to be capable to handle 100T challenging multi-hop queries.

Performance: MPP architecture can do this AML flow parallelly for all accounts. It’s a data mining problem involves both unsupervised clustering and semi-supervised rule filters. You need to examine each account and its transactions.

Advanced Aggregation support from Query Language: GSQL query language’s accumulator ingredient makes this ad-hoc vertex-centric aggregation easy. I don’t see how other query languages can do this. The closest one may be SQL stored procedure, but it’s not as good as an accumulator since graph query is vertex oriented, we need to leave side-effects (runtime attributes) on vertices for later iteration examination.

Mutability: TigerGraph allows queries to insert nodes and edges. This makes alert and case generation possible.

Contact

If you need to see an AML demo, please contact us here info@tigergraph.abstage.xyz.