# Engagements Source: https://docs.rem.money/source/engagements/index How working with REM runs: one workflow, fixed scope, explicit production criteria. REM starts with one network or application and one workflow, and gets it into production before adding breadth. Delivery is hands-on at first; the connectors, mappings, workflows, and controls built along the way are what become reusable product. ## How an engagement runs A short working session to pin down the workflow, the data, the destination system, and what "correct" means. See the questions below. One live workflow, delivered in roughly four to six weeks against written production criteria. For example: authorised ledger view → REM connector → canonical events → your ledger or stream → reconciliation and audit trail. The pilot moves to production once the agreed criteria are met, in the deployment mode your security boundary allows. Ongoing deployment, support, and SLAs for the running workflow, then expansion to the next workflow or network. ## Example first engagements * Private Zk chain application → customer Kafka, Snowflake, or accounting system * Tempo Zone → ledger, reporting, and reconciliation backend * Private-EVM tokenised bond → lifecycle events and books-and-records synchronisation * Custody or provider feed plus ledger view → settlement reconciliation * Stablecoin product → production data, delivery, and operational controls * Multi-entity stablecoin flows → intercompany settlement evidence and reconciliation ## Discovery questions Come ready to talk through: 1. Which event or state must appear in which system? 2. What is rebuilt or handled manually today? 3. Which failures are expensive, common, or audit-sensitive? 4. Who owns the problem, the budget, and the production decision? 5. What data is authorised, and where may it be processed? 6. What finality, latency, completeness, retention, and residency rules apply? 7. Which actions remain under your or your custodian's control? 8. What result would convert a pilot into production? ## A good fit Engagements work best when there is: * a live product or a dated production launch; * an urgent, recurring integration or operational problem; * authorised access to the required data; * a named owner in product, engineering, implementation, treasury, finance operations, or controllership; * a real destination system and a correctness requirement; * an agreed dataset and security boundary; and * potential reuse across customers, entities, or deployments. REM does not take on speculative token issuance, free generic demos, or custom development unrelated to the workflow. ## Ways to work together | Model | What it looks like | | :--------------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Direct** | REM delivers the workflow for your application, infrastructure, stablecoin, RWA, network, or treasury team. | | **Embedded / OEM** | REM becomes the embedded or white-label integration backend inside your product, deployed for each of your customers. | | **Subcontracting** | REM provides specialist, white-label delivery capacity inside a prime contractor's client engagement, with clear scope, documentation, security boundaries, and non-solicitation terms. | | **Managed deployment** | REM runs, supports, and maintains the workflow after it goes live. | ## Get in touch Bring the network, the destination system, and the records that have to agree. [hi@rem.money](mailto:hi@rem.money) # Entry profiles Source: https://docs.rem.money/source/intro/entry-profiles The five situations where REM usually starts, and the fixed-income domain REM builds depth in. REM starts where one workflow is urgent, the data is authorised, and a real destination system has to be correct. These are the five most common starting points. ## Private-ledger integration Connect a Zk EVM chain application, Tempo Zone, private EVM, or permissioned platform to a customer's existing infrastructure, without implying access beyond the authorised participant view. REM Edge deploys inside the customer's permitted boundary. Canonical history means the authorised participant view, with explicit provenance and visibility scope. It never implies global completeness. **Typical first workflow:** private Zk chain application → customer Kafka, Snowflake, or accounting system; or Tempo Zone → ledger, reporting, and reconciliation backend. ## Stablecoin and RWA infrastructure Give a funded product company the missing data, workflow, settlement, and reconciliation layer it needs to move from product demand to production operations. **Typical first workflow:** stablecoin product → production data delivery, operational controls, and reconciliation. ## Emerging-network enablement Provide connectors, canonical data, enterprise delivery, and operational tooling where a new DLT or blockchain platform lacks a mature integration ecosystem. Application teams on the network get a production backend without each building their own. ## Multi-entity settlement Coordinate stablecoin settlement and reconciliation across subsidiaries, franchises, operating entities, wallets, providers, bank accounts, and internal ledgers. **Typical first workflow:** multi-entity stablecoin flows → intercompany settlement evidence and reconciliation. ## Deposit operations Own the correctness lifecycle of a deposit, not just the notification: ```text theme={null} Observed → Pending → Confirmed → Finalised → Creditable → Credited → Reconciled ``` REM handles reorgs, duplicates, unsupported assets or networks, attribution failures, missing tags or memos, finality policy, replay, idempotent delivery, and three-way reconciliation between chain, custody or provider, and internal ledger. Each supported chain is watched once. Transfer-shaped activity is matched against an indexed address registry rather than polling every customer address. **Typical first workflow:** custody or provider feed plus ledger view → settlement reconciliation. ## Fixed income: the leading domain Fixed income is the semantic domain REM builds the most depth in. It is not necessarily the first sale. Reusable lifecycle coverage includes: * issuance, allocation, DvP settlement, and beneficial ownership; * coupons, accruals, tax, calls, puts, defaults, and amendments; * collateralisation, repo, margin, and substitution; * maturity, redemption, cancellation, and archival; and * books and records, reporting, servicing, and exception management. REM records and reconciles these lifecycle events. The issuer, agents, and licensed providers perform them. **Typical first workflow:** private-EVM tokenised bond → lifecycle events and books-and-records synchronisation. A fixed-coupon note on a private Tempo Zone, with lifecycle events synced to books and records. # How REM works Source: https://docs.rem.money/source/intro/how-rem-works The product loop and the five modules that make up REM. ## The product loop Every REM deployment runs the same loop, whatever the network or workflow: ```text theme={null} Observe authorised activity → establish canonical history and state → normalise financial meaning → enforce policy and approvals → execute durable workflows → reconcile every system → retain evidence and exceptions ``` The promise is correctness across the full lifecycle, not fast notifications. ## Modules REM is delivered as five modules. A first engagement typically uses Edge, Model, Sync, and Reconcile; Flow is added when the workflow needs automation or customer-controlled transactions. Connectors for ledgers, custody systems, and enterprise sources, deployed privately, in a VPC, on-premises, or embedded in a vendor's product. Edge handles authorised access, checkpoints, provenance, gap detection, reorgs and finality, corrections, and replay. Canonical financial objects and lifecycle semantics. A transfer, deposit, coupon, settlement, or redemption means the same thing in every downstream system, regardless of the network it came from. Delivery through APIs, webhooks, Kafka-compatible streams, databases, warehouses, files, and enterprise schemas. Durable automation across services, databases, approvals, and customer-controlled transactions, with retries, idempotency, timeouts, and execution history. Continuous comparison across ledger, custody or provider, bank, and internal books, with explainable breaks, an investigation lifecycle, and recovery evidence. ## The first offer REM sells one embedded integration backend for one live workflow: ```text theme={null} Authorised ledger or application view → REM connector → canonical financial events and state → customer API, stream, database, or accounting system → reconciliation, exceptions, and audit trail ``` The engagement has to measurably reduce integration time, operational errors, reconciliation breaks, or maintenance. ## How REM expands Once the first workflow is live, REM grows along a fixed sequence: One application connected to one enterprise system. Stable financial objects and lifecycle events. Reconciliation, exceptions, evidence, and materialised state. Policy, approvals, durable workflows, and controlled execution. Asset servicing and obligation management. Templates, OEM distribution, and partner-built modules. # Overview Source: https://docs.rem.money/source/intro/index REM is the financial control plane for tokenised finance. It makes tokenised-finance applications work with the systems their customers already use. ## What REM is REM is the financial control plane between tokenised financial networks and existing institutional systems. It turns authorised ledger activity into canonical financial state and events, coordinates durable workflows, and reconciles outcomes across chains, custody, books and records, and enterprise systems. In plain language: **REM makes tokenised-finance applications work with the systems their customers already use.** ## The problem Tokenised-finance applications span public chains, private Zk EVM chains, Tempo Zones, custody platforms, bank rails, and internal ledgers. The application usually works. What breaks in production is everything around it. Something has to: * obtain the data each participant is authorised to see; * reconstruct canonical history, state, finality, and corrections; * translate network-specific primitives into financial meaning; * expose stable APIs, streams, webhooks, and enterprise schemas; * coordinate approvals and retryable offchain and onchain work; * compare expected and observed state across systems; and * retain operational and audit evidence. Vendors end up rebuilding this backend for every customer. Private networks make it harder: data is participant-scoped and often has to stay inside a VPC, customer cloud, or on-premises environment. A public SaaS indexer cannot crawl a universal dataset on your behalf. ## What REM delivers The product loop and the five modules: Edge, Model, Sync, Flow, and Reconcile. Private-ledger integration, stablecoin and RWA infrastructure, emerging networks, multi-entity settlement, and deposit operations. Source connectors, canonical ingestion, the financial model, workflows, and reconciliation. Managed cloud, dedicated VPC, customer cloud, on-premises, or embedded. ## Supported sources | Source | Examples | | :---------------------------- | :------------------------------------------------------------ | | **Public EVM networks** | Ethereum, Base, Arc, and other EVM chains | | **Private EVM networks** | Private Zk EVM chains and permissioned EVM platforms | | **Tempo** | Tempo and Tempo Zones, through the interfaces each exposes | | **Custody and providers** | Custody, wallet, and provider APIs, files, and messages | | **Bank and internal sources** | Bank statements, internal ledgers, ERP and accounting records | Connectors are built for the network and workflow in an engagement. REM starts with one network and one workflow before expanding. ## What REM is not REM owns software for connectivity, canonical state, semantics, workflows, policy orchestration, reconciliation, evidence, integrations, and observability. REM does **not** own customer funds, balances, wallets, keys, custody, issuance, regulated execution, or the final action. The customer, bank, custodian, venue, or licensed provider remains the execution endpoint. REM is also not a generic compliance or KYC product, a public-chain indexer or analytics API, a network operator, or a trading product. Compliance, custody, and treasury systems are things REM connects to, not things it replaces. ## Work with REM See how an engagement runs, from discovery to a production-bound pilot. # Architecture Source: https://docs.rem.money/source/platform/architecture Responsibilities and boundaries across REM's source, canonical, semantic, execution, and reconciliation planes. ## System model ```text theme={null} NETWORK / SOURCE PLANE Public EVM · private EVM · Tempo · custody · bank/internal sources ↓ CONNECTORS + CANONICAL INGESTION Authorised access · checkpoints · provenance · gaps · reorg/finality · corrections ↓ CANONICAL JOURNAL + RAW ARCHIVE Transactional outbox · durable event log · permitted object archive ↓ PROCESSING / SEMANTIC PLANE Decode · transform · enrich · canonical financial model · materialised state ↓ CONTROL / EXECUTION PLANE Policy · approvals · durable workflows · transaction intents · customer signing ↓ INTEGRATION + RECONCILIATION APIs · webhooks · DB · event bus · ERP · custody · internal ledger · evidence ``` The durable abstraction is **canonical ingestion → financial state and semantics → controlled execution → reconciliation**. The components underneath each plane are replaceable; the contracts between planes are not. ## Source connectors Connectors (REM Edge) cover: * Tempo Zones and public Tempo/EVM interfaces, as exposed; * private and public EVM networks; and * custody, provider, and internal-ledger APIs, files, and messages. Every connector provides: * live ingestion and bounded historical backfill; * explicit participant authorisation and visibility scope; * source-native ordering, offsets, and provenance; * gap detection, resumable checkpoints, and deterministic replay; * finality, reorganisation, correction, and compensation semantics; * tenant isolation and permission-aware filtering; and * a raw record sufficient to reprocess when policy permits. An EVM archive node is not required just to detect transfers or ingest historical logs. It is required when a workflow needs arbitrary historical state or calls against old blocks. Blocks and logs, traces, and historical executable state are treated as separate requirements. ## Canonical journal Ingested records are published to a canonical stream through a transactional outbox, so database state and stream publication cannot silently diverge. The stream separates raw records, canonical records, reorgs, finality updates, and corrections. REM always keeps the raw or source-faithful record. A derived warehouse is never the only copy. ## Decoding and semantics The ingestion layer does not need to understand every ABI or business shape. Decoders are registered by network, contract or application, schema, and event signature: ```text theme={null} raw record → generic protocol/ABI decoder → application-specific decoder → institution-specific financial transformation → canonical financial event ``` ABI decoding answers what the bytes mean technically. REM's semantic transformation answers what they mean to the customer's treasury, accounting, settlement, or reconciliation process. ## Canonical financial model The canonical model (REM Model) is REM's semantic centre. **Core objects** | Group | Objects | | :------------- | :----------------------------------------------------------- | | Sources | `Network`, `SourceRecord`, `LedgerTransaction` | | Reference data | `Asset`, `Instrument`, `Account`, `Entity`, `Counterparty` | | Movements | `Position`, `Transfer`, `Deposit`, `CashMovement` | | Obligations | `Obligation`, `Settlement`, `Entitlement`, `CorporateAction` | | Control | `Policy`, `Approval`, `Workflow`, `ReconciliationBreak` | **Event envelope.** Every canonical event carries: * stable event and causation identifiers; * source provenance and authorisation scope; * source, effective, observed, and processing timestamps; * schema and mapping version; * parties, accounts, assets, quantities, and status; * finality and correction state; and * trace links from the raw source through every downstream action. Lifecycle events are prioritised by what the first design partner needs: deposit observation, finality, and credit; fixed-income issuance, transfer, coupon, maturity, and redemption; settlement; collateral; and reconciliation exceptions. ## Workflows and execution REM Flow runs durable workflows for meaningful financial operations, not one heavy workflow per raw log: ```text theme={null} HTTP · schedule · stream · onchain event · manual approval → durable workflow (policy, identity, approvals, idempotency) → HTTP / database / sub-workflow / transaction intent → transaction manager → signing interface (KMS, HSM, vault, or custodian) → network → receipt and finality observation → reconciliation ``` Workflows own retries, idempotent external effects, timeouts, recovery, and execution history. For onchain writes, the transaction manager owns intent persistence, nonce allocation, signing requests, submission, receipt tracking, and resubmission. REM policy owns fee and replacement rules, stuck-transaction handling, finality thresholds, and approval gates. All writes from a signing address pass through one nonce authority. The signer is an interface to the customer's KMS, HSM, or custodian. REM never becomes the custodian and never holds keys in production. ## Reconciliation REM Reconcile compares canonical ledger or application state with custody and provider records and the customer's own ledger. It supports: * configurable matching keys, tolerances, and time windows; * missing, duplicate, late, out-of-order, and amount or status mismatch detection; * finality- and correction-aware re-evaluation; * explainable evidence and versioned rules; * an investigation, ownership, resolution, and reopen lifecycle; * metrics for completeness, aging, recurrence, and operational risk; and * deterministic reruns after backfill or mapping changes. ## Private-ledger profile On private ledgers, REM assumes participant-scoped data and authorised APIs, not a globally crawlable chain. REM Edge is deployed inside the customer's permitted boundary, and canonical history means the authorised participant view, with explicit provenance and visibility scope. See [Deployment and security](/source/platform/deployment-and-security) for how private deployments are run. # Deployment and security Source: https://docs.rem.money/source/platform/deployment-and-security Where REM runs, what stays under your control, and the operational guarantees REM is built around. ## Deployment modes REM runs wherever the security boundary requires. The same control plane supports every mode. REM operates the deployment in an isolated environment. Single-tenant infrastructure with isolated networking and keys. Deployed into your cloud account, under your policies. Deployed inside your own data centre. REM runs as the white-label backend inside a vendor's own product. Private deployments keep secrets, retention, networking, observability, and upgrades under customer control. ## What stays with you REM does not own customer funds, balances, wallets, keys, custody, issuance, regulated execution, or the final action. * **Signing** goes through an interface to your KMS, HSM, vault, or custodian. Local keys are used only in development. * **Execution** of regulated actions remains with you, your bank, your custodian, or your licensed provider. * **Data** is limited to the participant view you authorise, processed inside the boundary you define. ## Control plane * RBAC, service identities, secret management, and least privilege * Data retention, residency, tenant isolation, and participant visibility controls * Versioned schemas, mappings, policies, and workflows * Metrics, logs, traces, alerts, incident evidence, and replay controls * Encryption, isolated environments, and reproducible deployments ## Correctness guarantees * At-least-once ingestion with exactly-once **business effects** through idempotency * Recovery without silent loss, and complete raw-to-action traceability * Explicit finality, correction, and manual recovery semantics * One nonce authority per signing address for any onchain write ## Observability Deployments emit OpenTelemetry-compatible metrics, logs, and traces, and can forward to your existing observability stack. Incident evidence and replay controls are part of the control plane, not an add-on. # Interfaces Source: https://docs.rem.money/source/platform/interfaces How canonical events and state reach the systems you already run. REM Sync delivers canonical financial events and state into existing systems. REM integrates these systems; it does not replace them. REM does not publish a public, self-serve API. Interfaces are configured per deployment against the destination systems in scope, and their schemas are versioned with the canonical model. ## Delivery interfaces | Interface | Use it for | | :------------------------------------ | :------------------------------------------------------------------------------------- | | **REST / OpenAPI** | Querying canonical state, lifecycle status, and reconciliation results | | **Webhooks** | Pushing lifecycle events (for example, a deposit becoming creditable) to your services | | **Kafka-compatible streams** | High-volume event delivery with replay into your own event backbone | | **PostgreSQL and customer databases** | Materialized state written directly into tables you own | | **Warehouse sinks** | Snowflake and similar warehouses, where reporting requires them | | **Secure file exchange** | Batch delivery for systems that only accept files | ## Enterprise connectors REM connects to the systems around the ledger, as each engagement requires: * ERP and accounting systems; * custody and wallet providers; * treasury and bank systems; * compliance providers (KYC, KYT, sanctions, Travel Rule), as inputs to a workflow; and * internal ledgers and books of record. ISO 20022 and FIX are supported only for a validated workflow that needs them. ## Delivery guarantees * **At-least-once ingestion, exactly-once business effects.** Every delivery carries stable event identifiers so consumers can apply idempotently. Replays and retries do not double-credit. * **Finality-aware.** Events carry their finality and correction state. Consumers can choose to act only on finalised events, and corrections are delivered as first-class events. * **Traceable.** Every delivered event links back to its raw source record and forward to every action taken on it. * **Versioned.** Schemas, mappings, and policies are versioned, and a change never silently rewrites history.