Fraude Intelligence ontology — quick tutorial

Goal

By the end of this tutorial you will have installed the Fraude Intelligence ontology pack, loaded six demo CSV files as silver tables, run the binding pipeline to materialise typed instances, and wired a simple agentic workflow that resolves a Transaction, traverses its parties links, and files a SuspiciousActivityReport — all using strongly typed ontology blocks.

Maya, our fictional compliance engineer, walks through this on a fresh tenant. All entity names, account numbers, and amounts in the demo data are fictional.

Prerequisites

You have a Scrydon deployment with the analytics, ontology, and agentic surfaces enabled. You're signed in as an org admin so you can upload packs and create managed tables.

Confirm by browsing to your Scrydon URL — you should see the workflow editor, the Analytics tab, and Ontology in the sidebar.

Step 1 — Install the pack

The Fraude Intelligence pack is a downloadable example, not a built-in. Install it in five drag-and-drop steps:

1. Download the bundle: fraude-intelligence.scrydon-pack.tar.gz (or the version-pinned scrydon-pack-fraude-intelligence-1.0.0.scrydon-pack.tar.gz alongside it).
2. In your Scrydon deployment, open Settings → Platform → Packs.
3. Drag the .tar.gz onto the drop zone (or click to pick the file). The dialog shows the bundle's packageId, version, and ontology contributes summary (11 object types, 9 link types, 5 action types, 10 identity rules, 9 bindings).
4. Tick I understand this pack is unsigned… and click Upload. The pack appears in your org catalog as Fraude Intelligence v1.0.0.
5. Switch to your workspace, open the Ontology marketplace, and enable Fraude Intelligence for the active workspace-environment.

If the upload returns Bundle invalid, the file may have been corrupted in transit — re-download and try again.

Step 2 — Inspect the schema

After installing, explore the schema before loading data:

Classes tab — the pack ships 11 object types:

RegulatedEntity · ComplianceAuthority · SupervisoryAuthority · RegulatorEntity · Person · CustomerRelationship · Transaction · SuspiciousActivityReport · CustomerDueDiligence · RiskAssessment · SupervisoryAction

Predicates tab — key links with their reverse names:

Layout tab — the schema graph renders a hub-and-spoke view with Transaction and RegulatedEntity as the two most-connected nodes.

Step 3 — Load the demo CSVs

Download the six demo CSVs (115 fictional rows, cross-referenced) and register them as silver tables in your tenant. Each download URL maps to the silver-table name the binding pipeline expects:

To grab all six in one go from a terminal:

mkdir -p fraude-intelligence-demo && cd fraude-intelligence-demo
for f in regulated_entities compliance_authorities transactions \
         suspicious_activity_reports supervisory_actions risk_assessments; do
  curl -O https://docs.scrydon.com/static/fraude-intelligence/$f.csv
done

Column headers are binding-contract headers — they match the columnMap values in the pack manifest exactly (e.g. transactions.transaction_id, EntityID, SAR.@id). Do not rename them before uploading.

How to register the tables (the exact path depends on your tenant's storage backend):

• StarRocks / Lakehouse backend: Use the analytics app's Data Sources panel (/data-sources) → Register Table → upload CSV → set the table name to the value in the table above.
• DuckDB / local dev backend: Drop the CSV files into the configured silver-table directory and call the /api/silver-tables/refresh endpoint to register them.
• Custom backend: Consult your storage configuration. The binding pipeline only requires that a table with the exact name is queryable via the analytics query interface.

Callout — column name format: The binding columnMap values use dot-notation paths (e.g. transactions.originator.name) and prefixed names (e.g. fius.fiu_id, SAR.@id). These are the literal column names the CSV must expose. The binding engine does not parse the dot as a nested path; it treats the full string as a flat column identifier.

Step 4 — Bind each row to your tables

Bindings are dynamic projections, not a batch ETL job. There is no "Run pipeline" step — rows are projected on demand when something reads them (a Get Object block, the graph view, or apiOntology.retrieve()). What you do here is wire each pack-shipped binding to one of your registered managed tables and confirm its column map is correct.

1. Return to https://<your-scrydon-url>/ontology and select Fraude Intelligence (pack).
2. Click the Bindings tab. Click the small i next to "Bindings" if you want the projection model summarised.
3. Under From a table, every silver-table binding lists the source name the pack expects (regulated_entities, compliance_authorities, …) on the left and the bound ontology class (RegulatedEntity, ComplianceAuthority, …) on the right. Each row carries one of three badges:
   • Ready — the table exists and every column the binding addresses is present.
   • Not ready — Table "<name>" not registered — you haven't uploaded a CSV with that logical name yet. Click Pick table on the row and choose one of your managed tables; the picker highlights an exact-name match as Match if you have one.
   • Not ready — Table missing columns: … — the table is bound but the columnMap references columns the table doesn't have. Open the row to fix it (Step 4b).
4. (Step 4b — only if a row says "Table missing columns") Click the row to expand it. The Column map editor shows every ontology property on the left and a dropdown on the right. The dropdown lists every column on the bound table; if the binding's stored mapping points at a column that doesn't exist any more, that option appears in red as <name> (missing). Repoint it to the right column and click Save — the badge flips to Ready without re-uploading the CSV. Sanitised SQL names (e.g. fius_fiu_id) and the original headers you uploaded (e.g. fius.fiu_id) are both accepted.
5. No further action is needed. The first time you call Get Object (Step 6) or open the graph (Step 5), the binding's projectPage runs against the silver table and returns typed instances.

Reference object counts you should be able to address once the data is loaded (the binding doesn't pre-materialise these — it queries the silver table on read):

Step 5 — Verify in the Knowledge Graph

1. Open https://<your-scrydon-url>/graph (the top-level graph view).
2. Instance nodes appear, coloured by class. Transaction nodes (teal) and RegulatedEntity nodes (indigo) are the most populous.
3. Click any Transaction node — the side panel opens showing all properties: transactionId, transactionType, amount, currency, originator/beneficiary fields, channel, and any riskIndicators.
4. In the side panel, click Expand neighbors. The graph grows along the FlaggedInSAR edges to SuspiciousActivityReport nodes where the narrative references that transaction.
5. Try clicking a RegulatedEntity node for Apex Remittance GmbH (EntityID e1a2b3c4-0015-4000-8000-100000000015) — you can trace its ActionTargets reverse links to see two supervisory actions and a risk assessment all pointing at it.

Note: TransactionParties (Transaction → Person) links will not appear yet because the demo data does not include a persons silver table. Person names appear as plain string properties on Transaction objects (originatorName, beneficiaryName). To materialise typed Person instances and traverse these edges, add a persons silver table binding against your own data source.

Step 6 — Use it from agentic

Switch to https://<your-scrydon-url> (the agentic app).

1. Open a workflow (or create a new one).
2. From the block picker, drag in Scrydon Ontology → Get Object (labelled Get Object after PR-C consolidation; operation = get_object).
3. In the block's configuration panel, the Type picker lists all 11 object types from the Fraude Intelligence pack. Select Transaction.
4. In the Instance ID field, paste one of the transaction IDs from the demo data, for example:

   txn-0001-aaaa-bbbb-cccc-000000000006

5. Click Run block. The trace panel shows the resolved typed payload — all 15 properties of the transaction, including the crypto-related risk indicators Maya flagged.

If you see an ONTOLOGY_REF_MISSING error at this point, the block cannot find the pack manifest — confirm that the pack is installed and the ontology API is reachable on port 3003.

Step 7 — Build a triage workflow

Wire a four-block workflow that mirrors Maya's manual triage process:

Trigger → Get Object (Transaction) → Traverse Links (FlaggedInSAR) → FileSAR action

Block 1 — Manual Trigger Set the trigger input schema to { "transactionId": "string" }. Pass txn-0001-aaaa-bbbb-cccc-000000000006 as the test payload.

Block 2 — Get Object Type = Transaction. Instance ID = {{trigger.transactionId}}.

Block 3 — Traverse Links Link = FlaggedInSAR. Source = output of Block 2. This resolves any SuspiciousActivityReport instances already linked to the transaction.

Block 4 — FileSAR action Operation = FileSAR. Subject ID = {{block2.transactionId}}. Input:

{
  "transactionId": "{{block2.transactionId}}",
  "severity": "critical",
  "narrative": "Automated triage: crypto-to-fiat layering pattern detected."
}

Run the workflow. The trace shows three typed payloads chaining through:

1. The resolved Transaction object.
2. The array of linked SuspiciousActivityReport objects (Block 3 output).
3. The FileSAR action output: { "sarId": "<new-sar-id>" }.

Three error variants to test:

Where to go next

• Extend the ontology — open the Proposals tab in /ontology to add new object types (e.g. BeneficialOwner) or link types without editing the pack manifest.
• Add custom Action Types — define additional compliance workflows (e.g. FreezeAccount, EscalateToAuthority) in the Action Types panel and wire them to the same typed objects.
• Replace the demo CSVs with your own data — register your production silver tables using the same table names. Bindings re-read the source on every query, so a data refresh is reflected immediately without re-running anything.
• Connect the Person binding — author a persons silver-table binding so reads project typed Person instances and unlock the TransactionParties edge traversal shown in Step 5.
• Review the pack manifest — packages/sdk-authoring/src/ontologies/templates/fraude-intelligence/index.ts is the authoritative source for all property definitions, link cardinalities, action input/output schemas, and identity rules.