Being the most money-involved domain of FinTech, payment processing systems like Adyen are often targeted by individuals or sophisticated organizations. Fraudsters try to generate many synthetic identities like hundreds of different email addresses or hundreds of spoofed IP addresses hoping to slip-in our payment systems, but with the help of our in-house Adyen Graph Database, we can always track them in real-time and block their fraud attempts even though they keep trying new tricks.

Adyen Graph Database

Adyen Graph Database is one of our in-house products that helps us to catch fraud attempts as well as identifying individuals and businesses trying to open an account in Adyen. You don't want to conduct business with shady companies or sole proprietors!

How can a graph data structure be helpful with payment data?

Use cases like catching fraud attempts or identifying a business or a person during their onboarding to Adyen and continuously checking if they comply with Adyen and payment regulations, pattern matching is a must. To see and explain how payments are connected to each other, relational data structures are not the best choice on their own. There can be changing patterns, many hops between fake identities, recursive and exhaustive search helps us to see all the patterns and connections in real-time, enabling us to track criminals such as fraudsters or shady business owners attempting to open an account and start to process payments with Adyen.

Why do we have our own graph database solution?

With the payments data, you should be able to look at that from two different but combined angles: as a transactional time-series data and as a connected graph to closely track potential criminals.

Having a pure traditional relational database system cannot help as they are not good at handling connections and patterns. Graph databases on the other hand are not good for processing high volume transactional data.

At Adyen, we need a completely different solution that combines both properties of graph databases and relational-transactional databases in a way that they also serve our specific requirements such as:

  • Transactional: because of the properties of payments data. combines
  • Multi-tenant: we process thousands of different companies' payments with different business needs. Also, for compliance reasons, it does make sense to process each company's data differently.
  • Data privacy: as a global financial institution, we encrypt any PII(personally identifiable information) data before processing and persisting.
  • Multi-regional: since we process payments for global companies, we need to provide our services also with the different needs of different regions. Therefore, multiple data and service regions is key.
  • High-availability: we should be ahead of the game before criminals. Real-time assessments rely on our high-available services to keep track of fraudsters.
  • Visibility and explainability: We should be able to answer questions like how and why things are happening when deciding both for regulatory purposes and for providing the top-quality service to our merchants.

All these unique high-end requirements affect how we make decisions at Adyen. This resulted in the Adyen Graph Database being built on top of community accepted, open-source, relational database PostgreSQL and open-source persistence framework Mybatis which supports custom SQL, stored procedures advanced mappings, and programming-language-like control statements that is managed by our internal graph-engine written in Java.

At Adyen engineering, we believe in the simplicity of our code and our systems. Combining all the powerful features of PostgreSQL such as handling high amounts of transactional data with features of Mybatis, such as being simple, explicit, and close to Java POJO objects allowed us to write our tailor-made SQL queries and stored procedures that are very high-performant.

The most powerful aspect of our graph database is that unlike a traditional graph database, it doesn't traverse the whole graph each time during a payment - which in our use cases is an unnecessary and yet very expensive operation. But instead, for the sake of performance, each time a payment is happening we asynchronously generate an overview of statistics and analytics information that is compact and contains all the information we need to detect criminal activities such as fraud.

Storing the relevant information in very simple, normalized key-value pairs we have a huge performance gain even on very big graphs.

Conclusion

With the exponential growth in our processed payments volume, we constantly look for improving our bespoke graph database solution to always scale better, be more extensible without scarifying the ability to be always ahead of the game before criminals as they constantly try new ways to penetrate into payments domain.

Technical careers at Adyen

We are on the lookout for talented engineers and technical people to help us build the infrastructure of global commerce!

Check out developer vacancies
Developer newsletter

Get updated on new blog posts and other developer news.

Subscribe now
TechDev Talks 2020: How Etsy migrated their PCI environment to offset risk

December 11, 20204 Minutes

TechRescuing failed subscription payments using contextual multi-armed bandits

December 4, 20207 Minutes

TechOptimizing payment conversion rates with contextual multi-armed bandits

November 2, 20208 Minutes

See all
Sign up for the newsletter

By submitting this form, you acknowledge that you have reviewed the terms of our Privacy Statement and consent to the use of data in accordance therewith.

Attachments

  • Original document
  • Permalink

Disclaimer

Adyen NV published this content on 13 January 2021 and is solely responsible for the information contained therein. Distributed by Public, unedited and unaltered, on 13 January 2021 12:55:01 UTC