BLUF – Mapping requires two things; data and an ontology. Data is the map’s elemental basis for both physical and functional composition. An ontology is the framework to use data, making sense of what was collected and connected. Building smart ontologies with data we have, want, and could see in the future allows the map to continue being useful long after initial development.

*Note: this is likely the first in a series, so be patient. We will get through the various components in time. Meanwhile – ask questions, find flaws, see if we can’t break the construct. -scl

Background

To understand an organisation’s risk, trace out the potential impact to an incident, understand larger client/ supplier relationships and KYC, it helps to have a map. Looking at process flows, finding what needs shoring up for operational resilience, seeing larger pictures to find anomalies and potential threats all require data linked relationally to create a usable interface.

Often we hear people talk about mapping, looking to create ‘end-to-end’ visibility into broadly esoteric categories. It sounds good on the surface, but creating practical tools from theoretical concepts requires a solid framework. In this case it requires an ontology.

What is an ontology?

Standard Oxford definition to follow — no, we are not talking metaphysics — “A set of concepts and categories in a subject area or domain that shows their properties and the relations between them.”

Applying the definition in a slightly more digestible order:

• In a subject area or domain: for this exercise, we are talking the organisation as the top level, with capacity to break down to business lines, clients, suppliers, etc. Often a tricky starting point, misconstruction of the domain potentially sends the remaining efforts in undesirable directions.
• Shows their properties .. : another challenging proposition. Essentially delineating entities and relationships can be difficult. To see how these build without building, or accept failure as likely and be prepared to restart (not the voice of experience!). Make it simple: anything you can touch is an entity – a business, individual, etc. Every bit of information we have about them is a descriptive property captured in the entity’s scorecard.
  • So if the entity is a person, all the KYC information we have would be individual components of that person’s scorecard, along with their accounts, and any other pertinent information we have on them. Keeping a structure of what is useful information to know is important, as it allows you to make automated connections.
• …and the relations between them: also kept simple, we track connections between entities because something happened. Akin to building bridges, we want to keep it as simple as possible, only capturing what belongs between the entities.
• Set of concepts and categories: originally intended to refer to entities (most likely) we will interpret as another way of creating different data layers to interact with each other. Just as you could strip a physical map down to its topography or add borders, roads, retail locations. With an organizational map you can add and remove layers as well.

Makes sense? Likely not.

Let’s try an example.

Person A (now known as Alex) is a customer. All the KYC information, accounts, place of residence are aspects describing Alex and should be in a scorecard attached to his entity. Alex does business with Person B (Bob) as Alex’s vendor, and Company C (Coolio’s) as a client. Both Bob and Coolio’s are separate entities. The relations/ links are in the transactions we see:

• Alex pays Bob – from one known account to another known account, on a specific day at a specific time.
  • Alex is a customer, Bob is not (yet). We still keep an entity for Bob. This way we can maintain awareness of the ecosystem as a whole and, yes, identify potential customers and clients.
• Coolio’s buys supplies from Alex. Coolio’s is our organisation’s client. They each belong to a different business unit within the organisation; but we still can see their connection, we have all their KYC and track their transactions between our businesses.

Other links could be applied, depending on the entity. If we go back to my earlier post using people as the basis for our internal mapping, we might link to hierarchy, devices, processes or controls etc. Anything not considered a discernible property of the individual alone connects them to others.

This is the simple start. More on this in the next post.

-scl

*To caveat: I have done this before, helping build ontologies to use large datasets in link-analysis. There are other available methods to interpret data. I understood link-analysis and it worked best for me. So these interpretations are presented purely from the standpoint I would use to create an ontology.