DEVSTORY #11 : Counterparty Knowledge Graph (CKG)

Schedulers, Settlement analysts, and AR/AP professionals at a commodity trading operation need up-to-date operational reference data related to counterparties and service providers. Most systems of record used today by personas in these operational roles are out of date as soon as they are deployed as data changes quickly and the systems are reliant on people to keep them up to date.

Keeping reference data up to date across multiple firms calls for a central repository of this information. The information is updated once by the responsible party. Notifications of change can be sent to other business entities that can elect to update their systems of record manually or programmatically on some or all notifications.

A central counterparty knowledge graph, implemented using a graph database – Neo4j, contains a graph covering all aspects of the organizational information required by a trading counterparty to facilitate transactions. A representative subset of the information would include

  • organization structure ( organization, subsidiaries),
  • roles (settlements, accounting)
  • people at the organization who need to be contacted in case communications need to be sent

A trading firm stores its reference information in a central repository. Settlement contacts are one category of information of interest and queryable from the Counterparty Knowledge Graph (CKG). To expose the list of contacts related to the settlement role, for a particular commodity at the trading firm, there is a need to provide an endpoint that is manually or programmatically queryable.

Alternatively, a trading firm can subscribe to some or all changes to a counterparty’s data. When change notifications occur, data updates can be approved for update in system of records. Robotic process automation can be employed to trigger a workflow or autonomously update the relevant system of record with the updated changes.

The solution to this problem is a trading firm stores its reference information in the Counterparty Knowledge Graph (CKG). FAAS ( using OpenFAAS containerized functions on Kubernetes) and REST APIs implemented using Sanic Views exist to query the graph on demand for current up-to-date information about a counterparty. This method is used to pull data from the Knowledge Graph on demand.

Alternatively, a Socket.io implementation allows subscribers of the Counterparty Knowledge Graph to be notified of some or all events on specific or all counterparties. This method allows for events to be pushed to a subscriber. Web sockets enable real-time communication of events on data, that allow programmatic updates of a system of record internal to an organization.

An entity updates the information in the graph. Other entities can retrieve these changes on demand, periodically or receive notifications of change so that updates to internal systems of records can be triggered.