ComChain Alliance Releases Draft Schema for Normalised Call Data Records

OVERALL SCHEMATIC OF THE COMCHAIN STACK

Over the past few years the ComChain Alliance, CCA, has been set up to aid regulated markets with the issue of how to maintain regulatory compliance for communication records. Compliance is becoming ever more stringent whilst in parallel new means to communicate are becoming more prevalent. The conundrum is no more pronounced than with Voice Communication within Financial Services. Whilst there is an ever growing list of tools to: enable, record , transcribe, index and better analyse calls firms are limited by the fact that many solutions require turn key changes in infrastructure or potentially costly integration and maintenance projects.

The CCA was formed to create a normalised standard simplifying the process of integration or different services and tools. The goal was to enable firms to move up the value chain in leveraging the benefits of the new tools and services — such as Voice Transcription, WebRTC and AI based analytics — whilst maintaining compliance.

KEY DELIVERIES OF CCA

The solution was split into three key objectives:

  1. How to Configure such a solution enabling different services, users, resources to be easily managed across the infrastructure.
  2. How data is then Captured by different systems and through leveraging the normalised data schema it can be linked together and seamlessly.
  3. Finally how the data can be Accessed by internal risk and compliance teams, other solutions for analytics and indexing and even the potential for external regulatory bodies and clients. Noting that the data needs to be secured and proven to be immutable in accordance to the regulatory requirements.

The CCA has been working on a technology stack leveraging BlockChain Technology to enabling disparate parties to update their pieces of the communication meta data. Significantly the BlockChain also allows for the seamless distribution of configuration updates that can be consumed by all integrated services. In order for such a solution to be viable a major step is the delivery of a normalised data structure.

The Draft of the ComChain’s Normalised CDR Schema has now been released on the ComChain website.

The Data Structure is based upon JSON-LD (JavaScript Object Notation for Linking Data).

JSON-LD is a lightweight Linked Data format. It is easy for humans to read and write. It is based on the already successful JSON format and provides a way to help JSON data sources to interoperate

The first area is that of Configuration — this in effect provides a map of the network. The schema defines how systems should reference people, devices, communications channels, organizations, groups and so on, based upon the core structures published under schema.org. The schema further defines the responsibilities for the capturing of content about calls between the parties, for example, which system is capturing the Call Data Records and which the Voice Recordings. Finally the Schema defines a hierarchy of data ownership — which parties can control, who has access to what data in which time window based upon when a user was working for a given entity.

MAP OF THE COMMUNICATION ECOSYSTEM DEFINING USER IDENTITIES, GROUPS, LEGAL ENTITIES, COMMUNICATION RESOURCES AND DATA CAPTURING SOLUTIONS

Configuration is in reality a question of identity this may be the identity of someone, a group or something — such as a specific communication device. A person may have multiple identities within different groups but they will be linked together through their own Sovereign Identity. Similarly users will have use of multiple devices and for the defined period for which they have access to the devices the identity of the two will be linked together.

Users can decide which identities they need to use for their regulated roles and these will be linked back to the groups under which they are working. These can be organizations but also the organizational units and Legal Entity Identifiers. Once the entities are determined the regulatory requirements will be defined and the communities and device identities linked to the user will be defined along with the service providers needed to capture the underlying communication data.

The second key area is Capture — this part of the Schema defines how the data itself will be captured and stored, such that all providers are adhering to the same standard. Different systems are able to capture data in respect to a communication, such as, Call Data Records, Voice Recording details, Transcriptions or any other Meta Data. The normalised schema enables each provider to update records independently ensuring data around specific events are linked and common fields are normalised to simplify searching and analytics. Once Captured the schema defines how the data will be hashed and stored.

Capture of communication data has been readily available across almost any communication channel for many years. The ComChain, however sets a normalized standard for the capture of this data. Different providers capturing different data from Call Data Records to Voice Recordings are able to work independently updating records for the “identities“ to which they are configured.

Once the data has been captured and stored in such a manner the ability to provide Access to the underlying data can be given to systems defined by the holder of the regulatory data. The data, being normalized, can be consumed regardless of the underlying data capture provider enabling rich analytics and searching to be undertaken without complex and costly integrations.

Please contact us if you are interested in the specification. Further topics we will be exploring are the Leveraging Blockchain Technology in order to anchor the hashes of data captured across the disparate sources ensures the immutability of the data through the chain of custody. In parallel the linking of the communication data to the different user groups and identities provides a mechanism to seamlessly link conversations to trades undertaken between different LEIs. Finally the opportunity for trading entities to agree on a normalized structure for the capture and immutable storage of data can mitigate the need for duplication of content and as such further reduction to the underlying costs.