One experience.
A connected economy.

Give clients a clear view of accounts, recipients, payment instructions and portfolio records. Conventional controls and agent-assisted journeys share the same permissions.

Responsible party: Client workspace

Connection status: Working pilot; external services connect separately.

Bring onboarding reviews, payment approvals, transaction monitoring and policy decisions into an accountable employee workspace.

Responsible party: Institution

Connection status: Working pilot with role-based access.

Translate intent into a proposed action, show the details and obtain the required confirmation. Scope access to the person or workload; select a local or approved hosted model.

Responsible party: Institution + model operator

Connection status: Integration design; arbitrary external agents are not automatically connected.

Reuse identity for sign-in. Request separately consented verification metadata where supported. Your institution still decides eligibility and whether to open an account.

Responsible party: Identity provider + institution

Connection status: Sign-in and optional verification-summary consent are connected.

Authenticate and authorize each operation, route it to the responsible service, and return a traceable result. Core adapters need field mapping, safe retry rules and reconciliation.

Responsible party: Institution + integration team

Connection status: Existing-core adapters require implementation and acceptance testing.

Apply country policy, institution-selected sanctions sources and review rules. Record the officer, reason and policy version. Required screening must be available before the affected activity proceeds.

Responsible party: Institution compliance team

Connection status: Working Testnet pilot: Hybrid-ID screening is connected for all six selected lists. Country controls and shadow monitoring are active. Reviewed country-programme evidence is connected; source freshness and institution policy remain explicit.

Choose one authoritative core for accounts and balances. Native Hybrid Core provides the pilot ledger. In an existing-core design, route instructions to that core and synchronize confirmed results.

Responsible party: Institution core operator

Connection status: Hybrid Core pilot available; Temenos/Avaloq adapters are not active.

Add wallet capabilities to e-banking through an agreed custody and key-control model. Reconcile wallet positions separately from fiat account balances and distinguish pending from confirmed network activity.

Responsible party: Institution + custody provider

Connection status: Ecosystem capability; production Banking wallet integration must be scoped.

Bring price evidence and portfolio context into the workspace. Centralized exchange or decentralized exchange access requires supported assets, venue checks, wallet authority and separately tested execution.

Responsible party: Institution + venue/custody providers

Connection status: Research and simulated orders available; live trading is not connected.

Connect a licensed banking entity for the agreed account and settlement services. Identify the customer relationship, supported markets, currencies and commercial responsibilities.

Responsible party: Contracted licensed entity

Connection status: Partner role shown for planning; no universal access or licensing entitlement.

Connect supported payment rails, retrieve payment status, handle returns and reconcile provider statements. Activate only the services covered by the institution’s operating model.

Responsible party: Contracted payment provider

Connection status: External ACH/wire settlement requires a verified provider connection.

Connect an issuer and processor for an agreed card programme. Define issuing eligibility, card lifecycle, service requests and settlement responsibilities.

Responsible party: Contracted issuer + processor

Connection status: Pilot card requests; real card issuance is not connected.

Plan participation between approved institutions and workloads. Agree identity, permissions, information-sharing boundaries and the operations exposed by each participant.

Responsible party: Participating organizations

Connection status: Target connection pattern; each Banking network integration needs validation.

Extend selected services to connected networks under explicit agreements. Confirm counterparties, supported assets, data residency and the legal scope of each cross-network activity.

Responsible party: Each network + institution

Connection status: Network membership does not transfer licenses or execution authority.

Keep sensitive records private while publishing limited cryptographic commitments. Track publication and finality separately; a verified record demonstrates integrity, not the correctness of a compliance decision.

Responsible party: Institution + proof publisher

Connection status: Selected compliance-policy proofs are connected; not every conversation is publicly anchored.

Keep private records and agent memory within an approved storage boundary. Define encryption, retention, key ownership, retrieval rights and tested recovery for the deployment.

Responsible party: Institution data owner

Connection status: Ecosystem capability; Banking deployment and data paths need integration validation.

Prepare a recipient-safe collection, approve its content and grant specific access. Sharing context does not authorize a payment, grant a license or expose all private memory.

Responsible party: Knowledge owner + approved recipients

Connection status: Ecosystem capability; Banking agent connections are separately scoped.

Choose where customer records, models, keys and connectors run. Document every permitted external call and validate availability, recovery, support and residency requirements.

Responsible party: Institution + agreed operator

Connection status: Deployment options are designed and tested for each institution.