Graph-State Verification

1. The Structural Assumption That Fraud Exploits

Every payment system in operation today relies on a foundational model: verify the counterparty once, store the result, and reference it at the time of payment. This is true whether verification happens through KYB platforms, manual callbacks, bank-provided Verification of Payee services, or internal compliance checks.

The result of that verification — a confirmed entity name, a validated account, a screened director — is written into a database as a static record. It does not update. It does not watch for changes. It does not know when the entity it describes has structurally changed.

Business entities are not static objects. Between onboarding and payment execution, any of the following structural changes may occur:

• Ownership transfer to a new ultimate beneficial owner
• Director substitution — sometimes filed specifically to reroute payment authority
• Account migration to a different institution or jurisdiction
• Entity dissolution and re-registration under a near-identical name
• Domain transfer or registrar change on the entity's primary communication channel

Each of these changes is recorded in public registries. None of them trigger a notification in any standard verification tool. The onboarding record persists unchanged. The wire executes against a stale verification state.

This is the gap. Not a technology gap — a continuity gap. And it is the structural foundation of the majority of B2B payment fraud.

2. Why Attribute-Level Detection Fails

The conventional response to this problem is rule-based detection: flag any IBAN change, alert on director updates, require re-verification when registration details are modified.

This approach operates at the attribute level. It evaluates individual data points against predefined thresholds. But payment relationship fraud is almost never a single anomalous attribute — it is a pattern distributed across multiple attributes, each individually within normal bounds, that becomes anomalous only when read as a connected structure.

No individual rule catches this. The signal is not in any single attribute. It is in the graph.

This is the fundamental limitation of attribute-matching systems, including most fraud detection platforms currently deployed in enterprise payment workflows. They evaluate nodes in isolation. They do not read the edges.

3. The Knowledge Graph Model

sikker.me maintains a continuously updated knowledge graph of B2B payment relationships. Every entity that participates in a payment relationship within the network is represented as a subgraph — not a row in a database.

3.1 Node Taxonomy

The graph contains six primary node types:

Entity nodes represent legal business entities. Each entity node carries attributes sourced from authoritative registries: legal name, registration identifier, jurisdiction, incorporation date, current status, and registered address. Entity nodes are instantiated exclusively from registry sources and updated when those sources change.

Account nodes represent payment accounts associated with entities. Account nodes carry the account identifier (stored as a cryptographic hash — never in plain text), the institution code, the country of issuance, and the timestamp of first and most recent appearance in the network.

Director nodes represent natural persons who hold directorship or signatory authority over an entity. Director nodes are linked to entity nodes through typed edges that carry appointment dates, role classifications, and registry provenance.

Address nodes represent registered business addresses. An address shared by an unusual number of entities produces a naturally high degree in the graph, which is itself a signal.

Domain nodes represent internet domains associated with entities — used in invoicing, email communication, and corporate identity. Domain nodes carry registration date, registrar identity, and modification history.

Relationship nodes represent the payment relationship between two entities — the edges connecting a payer entity to a destination account through a verified or unverified binding.

3.2 Edge Taxonomy

Edges in the graph are typed and carry provenance metadata:

REGISTERED_AT        Entity → Address     (source: registry, timestamp)
HOLDS_ACCOUNT        Entity → Account     (source: open banking / registry)
DIRECTOR_OF          Director → Entity    (source: registry, appointment date)
PAYMENT_SENT_TO      Relationship → Account (source: network signal, anonymised)
DOMAIN_ASSOCIATED    Domain → Entity      (source: WHOIS / certificate transparency)
SHARES_DIRECTOR      Entity ↔ Entity      (derived — computed from shared director nodes)
SHARES_ADDRESS       Entity ↔ Entity      (derived — computed from shared address nodes)

Derived edges are computed at query time from the current graph state — ensuring structural signals reflect live topology rather than cached inferences.

3.3 Graph Properties and Why They Matter

Degree centrality of an account node — how many distinct entity names have been associated with a single account across the network — is a direct fraud signal. A legitimate business account typically has a degree of one. An account used for payment redirection may have a degree of three or more within a 30-day window.

Temporal clustering of attribute changes on an entity subgraph — director change, account change, and address change occurring within a compressed time window — is a structural signature of entity takeover, invisible in a flat database.

Hub density at address nodes — the number of recently incorporated entities sharing a single registered address — is a well-documented indicator of shell company infrastructure, visible as a natural topological feature.

Neighbourhood similarity between entity subgraphs — measured through vector embeddings of local graph topology — enables detection of structurally similar fraud patterns across unrelated entities without requiring explicit rule authorship.

4. The Ambient Verification Protocol

sikker.me does not verify counterparties in response to human requests. It verifies them continuously — ambiently — as a background process that runs on every payment relationship in the network simultaneously.

4.1 The Verification Loop

Phase 1 — Registry synchronisation. The graph maintains active subscriptions to authoritative business registries globally. When a registry publishes a change — a new director appointment, an address modification, a status change — the corresponding node updates within the synchronisation window. Event-driven pipeline: the registry publishes, the graph consumes, the node updates.

Phase 2 — State comparison. When an outbound payment instruction enters the system, the protocol compares the current state of the counterparty's subgraph against the state confirmed at the most recent prior verification — evaluating entity identity continuity, account binding stability, director continuity, and structural anomaly.

Phase 3 — Verdict emission. The comparison produces one of three verdicts. Not a score. A verdict.

CONFIRMED     — current graph state matches verified state. Wire proceeds.
MISMATCH      — structural deviation detected. Wire held. Specific deviation cited.
UNVERIFIABLE  — registry data incomplete or unavailable. Honest signal. Manual review.

The verdict is emitted in under three seconds — immutable, written to an append-only audit log with the full subgraph state, specific nodes and edges evaluated, and registry sources consulted.

4.2 Why Three Verdicts, Not a Score

Score-based systems produce a number — typically between 0 and 100 — that a human must interpret depending on their training, risk appetite, workload, and time pressure.

Verdicts eliminate interpretation. CONFIRMED means proceed. MISMATCH means hold and review the specific deviation. UNVERIFIABLE means the system is honest about its coverage limitation. A score of 47 requires a decision. A verdict of MISMATCH requires a phone call to the supplier. The cognitive load is categorically different.

5. The Network Signal Layer

The most valuable signals in the graph are not sourced from registries. They are derived from the aggregate behaviour of the network itself.

5.1 Cross-Client Signal Propagation

Every verification contributes an anonymised signal to a shared intelligence layer:

{
  account_hash:    SHA-256(account identifier)
  entity_hash:     SHA-256(registry identifier)
  jurisdiction:    ISO 3166-1 alpha-2
  verdict:         CONFIRMED | MISMATCH | UNVERIFIABLE
  timestamp:       bucketed to ISO week (not exact — privacy constraint)
  anomaly_flags:   [list of triggered structural checks]
}

No payment amounts. No payer identity. No supplier names. No raw transaction data. Only derived, anonymised structural signals.

5.2 What the Network Sees That No Single Client Can

Cross-entity account reuse. Account node hash:7f3a... appeared in payment relationships with three distinct entity hashes across six clients in 30 days. No individual client sees more than one. The network sees all three.

Director hub anomaly. Director node hash:9b2c... linked to one entity with a 10-year history and three entities incorporated within the last 90 days. A trusted director name appearing on recently created entities is a known mule-network topology.

Velocity anomaly. Account node hash:4e1d... first appeared 9 days ago and has appeared in 47 payment instructions across 12 clients. Legitimate new business accounts do not acquire 12 independent payment relationships in 9 days.

Entity name drift. The same account hash appearing with "Northgate Supplies AS", "Northgate Supply AS", and "Northgate Supplies Limited" across different clients within 30 days. Each variation is plausible. The pattern across the network is not.

5.3 Privacy Architecture

The network signal layer is architecturally incapable of reconstructing individual payment relationships. Account and entity identifiers are stored exclusively as irreversible cryptographic hashes. Timestamps are bucketed to ISO week granularity. Payer identity is never stored in any form.

This architecture satisfies legitimate interest under GDPR Article 6(1)(f) for fraud prevention, consistent with the legal basis used by credit bureaus and payment fraud networks across the EU. A formal DPIA is maintained and available to enterprise clients under NDA.

6. Graph Neural Network — Structural Anomaly Detection

Beyond rule-derived signals, sikker.me deploys a Graph Neural Network (GNN) trained to recognise structural anomalies in counterparty subgraphs.

6.1 Why GNN, Not Traditional ML

Traditional ML operates on feature vectors — flat arrays of attributes extracted from individual entities. Effective for attribute-level anomalies, but structurally blind to relational anomalies. A GNN operates directly on graph topology, learning from the relationships between nodes rather than the properties of individual nodes.

6.2 Training Methodology

Positive class: Subgraphs confirmed through multiple independent verification cycles with stable structural topology over extended time periods.

Negative class: Subgraphs reconstructed from documented fraud cases — including cases from the founder's direct experience in bank legal departments — providing ground-truth labelling of structural patterns that precede payment fraud events.

The model retrains on a rolling window. Every human confirmation or override becomes a labelled training example — a continuous learning loop where the model improves with use.

6.3 Vector Embeddings for Structural Similarity

Each entity subgraph is embedded into a high-dimensional vector space. Structurally similar subgraphs cluster together regardless of whether they share any individual attributes — enabling anomaly detection by structural analogy.

When a new subgraph enters the network, its embedding is compared against known fraud cases. If cosine similarity exceeds a calibrated threshold, the subgraph is flagged — not because any individual node is anomalous, but because the overall structure resembles a confirmed fraud topology.

7. Ambient Intelligence — The Second Brain for Payment Trust

A live knowledge graph, continuously updated from registry sources, enriched by cross-client network signals, reasoned over by a GNN, producing verdicts in under three seconds — this constitutes ambient intelligence for payment trust.

Embedded. Not a tool a human consults. Embedded in the payment infrastructure — running on every wire, before execution, without being invoked.

Context-aware. Every payment instruction evaluated in the context of the full subgraph — entity history, director network, account relationships, neighbourhood topology, and behavioural pattern across the network.

Adaptive. Improves with every interaction. Every confirmed verdict reinforces confidence. Every override corrects. Accuracy compounds with participation.

7.1 The Compounding Property

The accuracy of the system increases non-linearly with the number of participants. Below a density threshold, each new client adds marginal signal. Above it, each new client adds disproportionate signal — contributing observations on counterparties that other clients are also observing, creating triangulation no individual perspective provides.

This is the primary structural moat. A competitor entering the market today would need not only the technical architecture but the time-distributed network signal from months or years of live verification history. It cannot be purchased or replicated from static data sources. It can only be built through sustained operation.

8. What Graph-State Verification Is Not

Not a payment execution layer. sikker.me does not execute, hold, or block payments. The verdict is a signal. The client's controls determine what happens next.

Not a compliance programme. It does not perform sanctions screening, AML monitoring, or KYC/KYB onboarding. It is focused exclusively on the structural integrity of the counterparty relationship at the moment of payment.

Not a score. Three verdicts, each with a defined meaning and a specific recommended action. No numeric threshold to calibrate, no analyst required to interpret output.

Not a rules engine. Structural pattern recognition — graph topology analysis and learned embeddings. Rules are brittle. The graph learns.

9. The Decision Framework

Every outbound wire passes through a single API endpoint before execution. The endpoint receives payee name, account identifier, and jurisdiction. It returns a verdict with the structural basis and registry sources consulted.

POST /v1/verify

{
  "payee_name":     "string",
  "account_number": "string",
  "jurisdiction":   "string"
}

→ Verdict, confidence, structural basis, registry sources, latency.
→ Under 3 seconds. Every time.

Integration requires a single POST request per payment instruction. No workflow changes. No dashboard. No human initiation. The human is involved only when the verdict requires judgment — and the verdict tells them exactly what to judge.

10. The Gap, Closed

Most payment fraud is preventable. Not because it is unsophisticated — but because the evidence is already in the public record. In registry filings. In director appointments. In account modifications. In structural relationships that change over time while verification records remain static.

The gap is not a detection problem. It is a watching problem.

Nobody watches after onboarding. The knowledge graph watches. Continuously. Ambiently. On every payment relationship. Until the wire leaves.

That is Graph-State Verification.