Secure Transaction Service (II): The Customer Registry and Transaction Registry Data Models

The Fexco Secure Transaction Service (STS) is a section of the Fexco Central API that offers a set of services related to the compliance of financial transactions and Fexco Customers. We’ll review here a section of the used data model related to two key components in the STS, the Customer Registry (a complete Database with all Fexco customers)and the Transaction Registry (a database with all of the financial transactions). Both registries are cross-business. That means they implement a certain level of abstraction onto their data model to allow an acceptable integration to the older source of data.

We have to say the STS is basically a federation of services aggregating data about customers, transactions and other types of information (contracts, sanctions, operations) related to Fexco customers. These services are accessible through the Central API as regular endpoints and message brokers and besides they are consumed as well by internal services by using other channels.

The goal is to offer to Fexco business units a complete information about compliance, customer details, transactions monitoring, etc. Besides, the STS offers graphical dashboards to monitor financial operations related to Fexco customers and other types of events by using digital footprint as sources. So, it is useful for many purposes:

• Compliance monitoring
• AML
• Detection of anomalies (Fraud Detection)
• KYC
• Marketing, and many more

You can find a general introduction to the compliance request to the STS in the previous post of this series.

The Customer Registry Data Model

The Customer Registry (CR) is a personal data repository. That's why it implements a set of policies and standards to make the CR compatible and usable according to the required regulations.

The main entity is the PII (Personally Identifiable Information) and it is strongly related to the personal data concept as it is included in the GDPR directive.

OK, OK, we'll try to make things easier..

Firstly, what is personal data in GDPR?
Well, the GDPR directive applies to personal data, meaning any information related to an identifiable person who can be directly or indirectly identified in particular by reference to an identifier. This definition provides for a wide range of personal identifiers to constitute personal data, including name, identification number, location data or online identifier, reflecting changes in technology and the way organizations collect information about individuals.

Is Personally Identifiable Information (PII) the Same as Personal Data?
The term Personally Identifiable Information doesn’t appear anywhere in the GDPR. However, it does have a definite meaning in US privacy law. Therefore the term in itself is likely to cause confusion to anyone seeking to comply with GDPR. For a concept that has become ubiquitous in both technological and legal worlds, PII is hard to define. In a nutshell, PII refers to any information that can be eventually used to distinguish one individual from another. This includes any information that can be used to re-identify anonymous data. This can solely refer to data that is regularly used to authenticate/identify an individual, this may be averse to information that violates the privacy of on individual, that is, reveal sensitive information regarding someone.

We could say that all PII can be considered personal data but not all personal data is Personally Identifiable Information. Developing a solid GDPR compliance program demands an acceptable commitment of Compliance Managers and IT architects going beyond the scope of the PII to examine the full spectrum of personal data as defined by the EU.

Standards to the Rescue? Seriously?

Yes! And in this case ISO/IEC 27018:2019 has been really useful. This spec is officially a Code Of Practice For Protecting Personally Identifiable Information (PII) In Public Clouds. You can read this post in the ANSI blog to know more about the composition of the spec.

We followed the recommendations and main principles in the standard. This process required a complete analysis of the existing structure of the existing sources of personal data to be aggregated as well as the available information to compose a new PII compliant with the bigger concept of Personal Data.

Finally we composed the model found below. It gathers the main conclusions from our analysis and it covers the main aspects of GDPR's personal data while keeping the PII concept.

The general model for the Customer Record includes the PII as the main entity.

What about the policies?

The first step to GDPR compliance in matters pertaining personal data is undoubtedly the risk assessment of how existing data is being stored and accessed, the level of risk attached to it and whether it contains any PII. The data might be stored on server file systems, databases or even on an end user’s physical storage or cache. Becoming GDPR compliant will mean that we are not only protecting more data types in the future but will also involve dissipating more effort in the identification of existing data that initially wasn’t considered personal data. It is important to note that we cannot limit our scope to the data we hold as if it were a closed system. Nowadays, people typically interact with interconnected systems, and GDPR mirrors that. In such scenarios, organizations should focus outward, and infer who in their ecosystem can connect with an attribute to another, from the multiple varying paths to re-identification within their ecosystem.

Additionally, GDPR requires that a document ‘opt-in’ consent must be provided by each individual. The consent has to explicitly pinpoint the data collected, how it is going to be used and how long it will be retained. Organizations also have to provide participants with an option to remove their consent at any given time and request their personal data be permanently deleted. Participants should have the ability to get factual errors amended, and even request their personal data for review and use.

So, we did not stop with the data model as the reference standards and GDPR are requesting for the application of a whole set of policies. The data model is only the first step of our GDPR compliant personal data policy. The combination of data, data structure and policies conforms the Customer Registry.

 

We'll talk about the applied policies to personal data in a future post.

The Transaction Registry Data Model

In the other hand, we have the Transaction Registry (TR), which is another repository with all the valid transactions that have been happening in our system from heterogeneous sources/businesses. The TR is in fact a federated ledger of confirmed and verified transactions in businesses.

The transactions are abstract and they do not reflect any business specific entity or concept. They are pure transactions about money. The relationships with the PIIs is the key for AML detection and Compliance purposes and, in general, for anomalies detection.

In the case of the TR, we really don't care about the limits, thresholds or whatever used in businesses for compliance purposes. If we store something in here, it must be a previously validated transaction in some business. So thanks to this, the TR structure is really simple.

At first, we though on follow the ISO 20022 in order to have our transactions more... standardized, but after read the book (ISO 20022 for me Dummies) we realized that this standard is too complex and cover a lot of things that we really don't care about, at last, we're not a bank!

So, as we said, keep it simple, we want to store transactions, this means, a guy buy / sell something and some money is moved from one place to another. Let's think like a journalist: How, Why, When, What, Where? Well, maybe the 'why' is not our field so let's change it for 'Who'

• WHEN? A transaction will happen in an specific date ( Transaction_date )
• HOW? Inside the Money object, we have a money_type which tell us what kind of payment was, cash, card, etc...
• WHAT? Again, we have inside Money the amount of money and it's currency
• WHERE? This an easy one, we store the business and the country where this transaction happens.
• WHO? And directly linked to @jdediego part, we have the info about who made the transaction.

With this simple structure, we could have enough information about transactions and we could make some yummy graphics for business purposes, as transactions per country/currency/person and any combination that you can imagine and show them in Power BI... but we will talk about that in another post!