The Follow the Money Model consists of four main concepts:
entities, references, interstitial entities, and streams

1. Node entities

These are the core objects: like Person, Passport, Company as in Figure 1. Each one of them is a standalone entity with its own id, schema and properties (usually, multi-valued lists of strings).

2. Edges (formed via entity references)

FtM does not use edges directly. Instead, they are created by properties of type entity. Refer to Figure 1.

3. Interstitial entities (the “edge-with-properties” pattern)

Relationships are formed with the help of entities and simple edges. These entities (that represent relationship carry metadata).

The Key Differences

Simple Edge

This is created by a property of type entity. For Example

• Passport → holder → Person
• It is just a pointer; no additional information can be stored on the edge.

Interstitial Edge

This is full entity that represents the relationship itself. For example:

• Ownership → owner → Person
• Ownership → asset → Company
• Ownership has its own properties which is an edge with its own attributes.
  • startDate
  • percentage

Comparing with Neo4J property graph edges:

Can the interstitial edges be related with Neo4J edges since they also can store attributes? While they look very similar there are some significant differences between the two:

• Neo4j edges are actual edges in the graph. They can store attributes directly on the relationship. For example:

(:Person)-[:OWNS {percentage: 51, since: "2020"}]->(:Company)

Whereas FtM interstitial entities are nodes not edges. It uses two simple edges to connect the relationship to a node representing an edge.

4. Streams

Now, we come to the fourth concept in FtM data model/ontology called streams. The stream is just a physical way of structuring the FtM entities. It is a sequence of FtM entities, one per line, saved in plain JSON, with no indentation, but separated by new lines. For example:

{"id":"1","schema":"Person","properties":{"name":["John Doe"]}}
{"id":"2","schema":"Company","properties":{"name":["ACME Corp"]}}
{"id":"3","schema":"Ownership","properties":{"owner":["1"],"asset":["2"],"percentage":["51%"]}}

It should NOT be confused with a file format. It is only a way of representing many entities in a linear, append-friendly form facilitating easy sorting. They are the universal interchange format within the FtM domain.

There are 69 schemata possible with in the FtM model, and there is no limit on the number of properties allowed per schema.

Why the id first is important?

The id first arrangement enables sort-based aggregation, deduplication, and canonical id merging. For instance, running the code below, we get a globally sorted entity stream.

sort stream.ftm > sorted.ftm

How deduplication works in FtM

Deduplication is the process of merging multiple entities with the same ID in a stream.

FtM streams are line‑delimited JSON, sorted by id. This sorting enables a simple but powerful deduplication algorithm. Sort the stream by id and then, merge adjacent entities with the same id works easily well.

There are two more terminologies that we need to cover in this article: ValueEntity and StatementEntity.

ValueEntity vs. StatementEntity

A ValueEntity is the canonical, flat, JSON‑serializable representation of an FtM entity which is used in FtM streams, ingestion pipelines, CLI tools, deduplication etc. It has a flat json structure with properties represented as lists. The main purpose of its design is streaming, sorting, and merging.

The rationale for following this structure for ValueEntities is that by keeping it flat, it is easy to sort, merge, process and also stream line by line as required. Additionally, they are very lightweight (no metadata) and works well for fast pipelines.

A StatementEntity is a rich, provenance‑aware representation of a single property value. This is used within some of the specific applications for indexing, lineage tracking, source attribution, auditing, and conflict resolution. In Figure 3, each line traces the source of the record. However, when they are consolidated into a ValueEntity (shown on the top), the metadata is discarded, and only the core (valuable) information is preserved.

Figure 4 shows how a ValueEntity is formed in the FtM stream pipeline.

Next Topic

The FtM Entities