Financial service providers

Package Torq discovery, eligibility, portfolios, workflows, events, and evidence into a white-label Earn platform for fintechs, wealth applications, advisers, or regulated service providers. Each customer keeps an explicit product, tenant, credential, data, and signer boundary.

Private Preview. Every customer tenant, application, origin, signer model, product set, and production environment requires controlled onboarding.

What you will build

• Multi-tenant control plane that provisions isolated Torq applications, keys, origins, scopes, and webhooks.
• White-label catalog, product-detail, eligibility, portfolio, deposit, redemption, and activity modules.
• Adapter boundary for user wallets, embedded wallets, customer HSMs, or customer MPC services.
• Tenant-scoped workflow orchestration, signed-event inbox, audit, support, and reconciliation.
• Complete integration kit your customer can deploy without learning internal Torq implementation details.

Each customer uses a customer-owned signer. Your service may orchestrate consent and policy, but it must not turn a server credential into transaction authority.

Prerequisites

1. Provider-level Torq Developer Preview agreement and an approved application-isolation model.
2. One Torq organization/application/key/origin/webhook boundary per customer tenant and environment, unless Torq has explicitly approved another tenant model.
3. Tenant authentication, authorization, encryption, retention, deletion, audit, and incident controls.
4. Declared customer signer adapters and a conformance suite for each wallet, HSM, or MPC integration.
5. Commercial, regulatory, disclosure, suitability, fee, support, and responsibility agreements.

Project files

The reusable Torq boundary is checked in at examples/developer-platform/earn-program-reference:

src/config.mjs         # strict environment and endpoint validation
src/torq-api.mjs       # authenticated API and wallet sessions
src/catalog.mjs        # deep investor product data
src/workflows.mjs      # exact prepared-intent executor
src/webhooks.mjs       # raw-body delivery verification
src/use-cases.mjs      # financial-service-provider profile

Recommended multi-tenant implementation:

control-plane/tenants/             # customer and environment provisioning
gateway/tenant-context/            # identity -> tenant -> application binding
modules/catalog/                   # product and detail experience
modules/portfolio/                 # positions, activity, fees, redemptions
modules/workflows/                 # proposed action and canonical lifecycle
adapters/signers/                  # wallet/HSM/MPC conformance adapters
events/tenant-inboxes/             # physically or cryptographically isolated
audit/tenant-evidence/             # scoped operational evidence
reconciliation/tenant-jobs/        # canonical state vs customer records

Complete data contract

Complete credit lifecycle

Make the complete credit lifecycle a reusable, tenant-bound module in every customer implementation kit:

Include src/credit-lifecycle.mjs, the two-ledger data model, negative tests, and the availability gate in the files delivered to each customer—not only in the provider's central service.

Build the integration

1. Define the tenant constitution

For every customer, record organization, application, environment, origins, keys, scopes, product allowlist, signer types, webhook endpoints, retention, limits, support owner, and policy version. Resolve this tenant context from authenticated server state, never from a caller-provided tenant ID.

2. Provision isolated Torq applications

Create separate applications and key material, then store only secret references in your control plane. Route requests with resolved tenant credentials and enforce that returned organization and application context match. Prevent cross-tenant cache keys, idempotency keys, queues, webhooks, logs, exports, and support lookups.

3. Build reusable read modules

Use src/catalog.mjs to power catalog and detail components. Surface exact asset, market, vault, allocation, liquidity, fee, activity, mobility, eligibility, and freshness fields. The module accepts a resolved Torq client, not raw credentials. It fails closed if a product is outside the tenant allowlist.

4. Add customer onboarding and partner application

Where applicable, use role.partner.partnerSubmitApplication through the same reviewed workflow boundary. Keep commercial approval, Torq program status, customer onboarding, and transaction eligibility as separate states. Application submission never implies production or signer authority.

5. Build the proposed-action contract

Normalize deposit, redemption, and supported servicing actions into a typed proposal with tenant, customer, product, amount, fees, signer, chain, disclosure version, and stable idempotency key. Show this proposal to the customer before any transaction is prepared.

6. Prepare inside the resolved tenant

Call POST /v1/workflows/prepare with the tenant's client and supported workflow, such as role.partner.partnerWrapperDeposit or role.partner.partnerWrapperRedeem. Persist the exact prepared response. Require preflight passed and reject mismatched organization, application, chain, product, signer, snapshot, or expiry.

7. Invoke the customer-owned signer adapter

Every adapter exposes getChainId, required simulation, and sendTransaction for an exact prepared intent. It cannot accept caller-selected targets or calldata. Run the same conformance suite against browser wallet, embedded wallet, HSM, and MPC variants, including cancel, timeout, wrong chain, changed intent, and resume behavior.

8. Register and complete canonically

Register each submitted hash through POST /v1/workflows/{requestId}/transactions, then wait for the transaction and GET /v1/workflows/{requestId} to reach final_success. Reread positions, activity, liquidity, and the affected product before your tenant-facing module shows completion.

9. Isolate webhooks and reconciliation

Resolve the tenant from the verified endpoint/secret binding, not event JSON. Verify raw bytes with src/webhooks.mjs, insert once into the tenant inbox, acknowledge, and reread canonical resources. Never allow one tenant's event, key, origin, workflow, or resource cache entry to appear in another.

10. Ship a customer implementation kit

Provide environment schema, signer interface, UI-state matrix, API/SDK version, error catalog, webhook verifier, test fixtures, Sepolia script, production checklist, support route, and upgrade policy. Point AI systems to AI & Agents and machine-readable docs; keep secrets and authorization proofs outside all model context.

Tenant-isolation tests

• Tenant A cannot read Tenant B resources, workflows, transactions, events, keys, or usage.
• A caller-provided organization/application identifier cannot override authenticated tenant context.
• Cache, idempotency, database, queue, webhook, log, export, and support paths include resolved tenant scope.
• Wrong Origin cannot use another customer's publishable key or wallet session.
• Signer adapters reject wrong chain, target, calldata, value, expiry, and tenant.
• Receipt or event without tenant-bound canonical final_success never updates customer state.

Production checklist

• Every tenant and environment has explicit applications, keys, origins, scopes, and webhook secrets.
• Tenant identity is server-resolved and included in persistence, caches, queues, events, and audit.
• Read modules expose complete canonical product data and fail closed on stale state.
• Every signer adapter passes one shared exact-intent conformance suite.
• No raw credentials, wallet proofs, or private customer data enter client bundles or AI systems.
• Completion requires transaction/workflow final_success and affected-resource reread.
• Webhook inboxes and reconciliation are tenant-isolated and idempotent.
• Cross-tenant, reorg, retry, signer-cancel, and upgrade tests pass on Sepolia.
• Private Preview, responsibilities, disclosures, support, and compatibility policy are contractual.

Run node --test examples/developer-platform/earn-program-reference/test/*.test.mjs, then follow projects and environments, SDKs, and AI integration.