How to test integrations with Thought Machine Vault

Thought Machine Vault integration testing checks that Vault and the systems connected to it exchange valid data and preserve the intended banking outcome. Tests exercise the deployed interfaces and configuration across system boundaries, including request handling, transaction processing, ledger state and downstream updates. The exact contracts depend on the Vault version and the bank's integration architecture, so use the specifications for the environment under test.

Map the integration boundary

Start by documenting the systems and interfaces in scope. A typical flow may connect a digital channel or payment service to Vault, then send transaction or account updates to a notification service, data platform or general ledger. Record which component owns each decision and which component is authoritative for each value.

Identify the available interface contracts for the specific deployment, such as APIs, events or messaging adapters. Capture required fields, identifiers, currency and amount formats, validation rules, error responses, retry behaviour and delivery guarantees. Also note which Vault product configuration and contract versions the test environment uses. An interface test against a mock can check an individual contract, but it cannot establish that the connected Vault environment processes the request correctly.

Prepare controlled test conditions

Use an isolated non-production environment with test accounts, known balances and controlled product configuration. Confirm that the required customer, account and payment data exist before execution. Keep test records traceable by using unique transaction references, and define how each test resets or cleans up its data.

Check environmental dependencies before interpreting a failure. Differences in product configuration, permissions, currencies, calendars, limits or downstream service versions can change outcomes. Record the relevant environment and configuration versions with the test results. Avoid production customer data; use synthetic or appropriately protected data.

Build tests around observable outcomes

Cover the normal flow and the behaviours that matter when components disagree or become unavailable. For a transaction, assert the response or acknowledgement, the resulting account and ledger state, and any required downstream event or record. Verify amounts, currency, transaction reference and status across boundaries. Where processing is asynchronous, wait for a defined condition or use a bounded polling period rather than relying on a fixed delay.

Include cases for invalid account or payment data, insufficient funds or a configured limit, duplicate requests, timeouts, retries and downstream outages. Verify that rejected transactions do not create unintended postings. For a timeout after submission, query the resulting state before retrying: the original request may have committed even if the caller did not receive its response. Test idempotency using the actual identifier and retry rules defined by the integration contract.

A successful API response alone does not prove the banking result is correct. Reconcile the transaction reference and amounts against the authoritative Vault state and the expected downstream records. Where the workflow produces ledger entries, check that the entries and resulting balances match the configured product rules. Keep assertions independent of incidental fields, such as generated timestamps, unless those fields are part of the contract.

Worked example: transfer between two accounts

Assume a channel sends a transfer request through a payment service to Vault. The expected outcome is a debit to the source account and a credit to the destination account, with the agreed currency and reference preserved.

1. Arrange two eligible test accounts with known balances and the required permissions.
2. Submit one valid transfer through the same integration path used by the application.
3. Check the response against the interface contract, then verify the transaction and account state in Vault.
4. Confirm that any required downstream notification or transaction record carries the same reference, amount and outcome.
5. Submit the same request again using the contract's retry conditions. Verify that the resulting posting behaviour matches the defined idempotency rules.

The account setup, fields and expected statuses in this example are illustrative. Adapt them to the bank's configured products and interface contracts.

Diagnose failures and retain evidence

Separate transport failures from business rejections and processing failures. Capture the request correlation identifier, interface response, relevant Vault transaction state and downstream processing status, with sensitive values masked. For delayed or missing events, check whether the source transaction committed and whether delivery or consumption failed. For mismatched balances, trace the transaction reference across the ledger and downstream systems before assigning ownership.

Run focused integration checks when interface contracts or configuration change, and include affected flows in regression testing. Keep contract checks fast and use environment-backed integration tests for behaviours that depend on Vault processing. For wider customer journeys across channels and services, use [End-to-end testing in banking] as a separate layer of coverage.