Technical validation for TrustField workflows

TrustField provides a structured operational layer for program intake, evidence, decisions, accounting controls, and partner handoffs. The sandbox allows technical teams to validate the workflow and integration model before a scoped production implementation.

Open developer sandbox Discuss an integration

Program templates

Program event types

10+

Adapter integrations

<2s

Sandbox ack target

3 considerations for program API integration

Cost-efficient operations

One program layer for intake, checklist, status, and exports — fewer portals and spreadsheets as corridors scale.

Evidence you can trust

TF program IDs, event history, and export bundles your MLRO can defend — citations in API responses and diligence exports.

Built for speed

Self-serve sandbox on trustfield.ca — register, poll status, and create handoff records in minutes without a sales call.

Payment-execution boundary

TrustField records compliance and operational workflow state. In its standard configuration, it does not hold funds, maintain payment accounts, initiate or authorize electronic funds transfers, transmit payment instructions, or provide clearing or settlement.

Where a customer requests an integration involving payment instructions or payment credentials, scope and RPAA applicability must be reviewed before implementation.

Live in 3 steps

Pick a program template, register for a TF program ID, connect your settlement partner. Your program connector is exercising the API loop in minutes.

Select a template
MSB corridor, B2B payout, embedded finance, or technical sandbox — each maps to checklist gates and export bundles.
Browse templates →
Register program intake
POST /api/register assigns TF-######, opens RPAA checklist, and records program.created in the append-only program record.
Start sandbox →
Configure partner handoff
Create payload-free handoff records, poll reconciliation.json for breaks, and deliver audit exports to your MLRO stack.
Reconciliation API →

Event-to-export pipeline

From handoff-record creation to compliance export — workflow state and evidence without custody or settlement on TrustField.

Program event

handoff_record.created · TF-000042 · INS-000128

State + evidence

Checklist % · adapter ack · program_events ledger

Operator export

GET /api/register/{id}/audit.json

Partner / MLRO

Webhook · diligence brief · compliance report

Program templates

Pre-built program paths covering MSB corridors, B2B payout, and technical sandbox evaluation.

MSB corridor program

Intake · checklist · partner map

→ Partner settlement

B2B payout program

Program ops · evidence export

→ Enterprise treasury handoff

Embedded finance

TF program ID · branded intake

→ Partner MSB of record

RPAA readiness track

Dual-track checklist

→ FINTRAC + BoC narrative

Technical sandbox

Full API loop

→ Engineering evaluation

Canada program compliance tracks

Evidence and workflow for regulated payment programs — partners execute settlement; TrustField exports state.

Canada · AML / MSB

· FINTRAC program ops
· Agent diligence (Oct 2025)
· STR/EFTR evidence export

Audit JSON · CSV · HTML compliance report

Canada · RPAA / PSP path

· Readiness checklist
· Supervisory narrative pack
· Partner settlement map

Diligence brief · checklist export

Program operator

· Continuous reconciliation
· Break detection
· Webhook delivery

reconciliation.json · program_events

Program intelligence

Know who is behind every program flow

Evidence-backed entity lineage for regulated programs — link TF program IDs to operators, settlement partners, and adapter handoffs with provenance metadata. Not on-chain wallet attribution.

12+

Program entity categories

Delivery modes

Yes

Provenance per entity

Real-time

Ledger refresh

Evidence-backed lineage

Every program party includes provenance: intake fields, partner slug, handoff providers, and adapter health — suitable for MLRO review and exam export.

Structured delivery

REST APIs, audit.json batch exports, and webhook program_events — integrate into your TM stack without replacing your analytics vendor.

Built around your program

Categories expand with Integration Program scope — corridor programs, B2B payout, embedded finance, and RPAA readiness tracks.

Coverage at program scale

Structured categories for regulated payment programs — not darknet or mixer wallet labels.

· MSB program operator
· Licensed settlement partner
· Market access adapter
· Payment rail partner
· Identity verification partner
· Corridor / B2B / embedded finance programs
· Compliance evidence export

Integration modes

Real-time

GET /api/register/{id}/entity-lineage.json

Batch

GET /api/register/{id}/audit.json

Events

program_events webhook stream

FAQs

Is this blockchain wallet labeling?: No. TrustField attributes program parties — operators, licensed partners, and adapters — to a TF program ID. We do not label anonymous wallet addresses or sell chain analytics datasets.
What makes the methodology defensible?: Each entity row cites provenance: registration intake fields, partner_organization records, and handoff provider usage with adapter health status.
Who uses program entity lineage?: MSB program operators, compliance leads, and integration engineers scoping production handoff — especially when FINTRAC program evidence must tie to a settlement party of record.
How do I integrate?: Poll entity-lineage.json after register and handoff records, combine with reconciliation.json and program-health.json for a full operator picture.

Entity lineage API recipe →

API recipes

OpenAPI, curl recipes, and webhook samples — sandbox loop without a sales call.

{  "full_name": "Sample MSB Program",  "email": "ops@partner-msb.ca",  "corridor": "CA",  "settlement_path": "fiat",  "partner_slug": "demo-msb-tor",  "consent_accepted": true}→ { "program_id": "TF-000042" }

Illustrative TF-000042 — your register response will differ.

Base URL

https://api.trustfield.ca

Core object

Every program receives a TF program ID (for example TF-000042). Individual handoff records use an INS handoff record ID.

Auth

In production, operators use X-Admin-Token and partners use X-Partner-Token.

OpenAPI JSON →API docs →

Recipe library

Complete the sandbox loop from register → status → checklist without a sales call.

Returns TF-###### program ID and pending status.

curl -s -X POST "$BASE/api/register" -H "Content-Type: application/json" -d '{"full_name":"Program Operator","email":"ops@example.com","corridor":"CA-CAD","consent_accepted":true,"registration_type":"program"}'

Poll program status

Lifecycle, handoff record count, and recent events.

curl -s "$BASE/api/register/TF-000042" | jq .lifecycle,.instruction_count,.recent_events

Update checklist item

Operator workflow — mark RPAA checklist steps complete.

curl -s -X PATCH "$BASE/api/checklist/TF-000042/items/rpaa-01" -H "Content-Type: application/json" -d '{"status":"complete"}'

Program reconciliation

Break detection — checklist vs handoff records vs event ledger.

curl -s "$BASE/api/register/TF-000042/reconciliation.json" -H "X-Admin-Token: $ADMIN_TOKEN" | jq .aligned,.break_count,.breaks

Program health score

Operator readiness index — not credit scoring.

curl -s "$BASE/api/register/TF-000042/program-health.json" -H "X-Admin-Token: $ADMIN_TOKEN" | jq .health_score,.grade,.summary

Program entity lineage

Evidence-backed party attribution — not wallet labeling.

curl -s "$BASE/api/register/TF-000042/entity-lineage.json" -H "X-Admin-Token: $ADMIN_TOKEN" | jq .entity_count,.entities

Program entity categories

Public category taxonomy for program parties.

curl -s "$BASE/api/program-entity-categories" | jq .count,.categories[0]

Webhook event sample

Ops and evidence hooks — handoff.prepared, handoff_record.created, and related program events.

{
  "event": "handoff_record.created",
  "program_id": "TF-000042",
  "handoff_ref": "INS-000128",
  "timestamp": "2026-06-13T12:00:00Z"
}

Event catalog

Event	When it fires
program.created	After successful intake
portal.verify.completed	Customer verification step complete
handoff.prepared	Payload-free handoff checkpoint prepared
handoff_record.created	Payload-free handoff record created
handoff_record.updated	Partner reports completion status

{
  "id": 42,
  "program_id": "TF-000042",
  "full_name": "Program Operator Ltd",
  "email": "integration@example.com",
  "corridor": "CA-CAD",
  "status": "pending",
  "registration_type": "program",
  "message": "Program intake received. Program ID TF-000042 is pending."
}

Sandbox intake Open program state sandbox Ops evidence story

Dev platform

Adapter health and venue catalog stubs — production partner handoff scoped by Integration Program SOW.

Integration health

GET /api/integrations/health — adapter configuration (no secrets exposed)

{
  "adapters": []
}

Market access catalog

GET /api/venues — integration patterns (public labels only)

{
  "count": 0,
  "demo_mode": true,
  "venues": []
}

Technical validation for TrustField workflows

3 considerations for program API integration

Cost-efficient operations

Evidence you can trust

Built for speed

Payment-execution boundary

Live in 3 steps

Select a template

Register program intake

Configure partner handoff

Event-to-export pipeline

Program templates

Canada program compliance tracks

Know who is behind every program flow

Evidence-backed lineage

Structured delivery

Built around your program

Coverage at program scale

Integration modes

FAQs

API recipes

Recipe library

Dev platform

Integration health

Market access catalog