One Platform, Many Configurations: Global Torque’s Modular Architecture
Choose your providers, configure your products and expand your channels on one shared operating foundation.
One operating core. Reusable modules. Multiple financial-product configurations. Conceptual illustration.
Global Torque lets institutions build and operate different financial products from the same reusable capabilities. An issuer can choose the product terms, supported cash and custody arrangements, ledger or distribution path, and delivery model that fit its business. The product keeps one operating foundation as those choices evolve.
That gives a tokenized note or fund room to change without turning every new provider, market or interface into a separate technology project. Product identity, approved rules, transaction coordination, ownership and servicing remain connected. The bank rail, custody and key-management arrangement, ledger, distribution channel or application surface can be configured around them.
This is the practical meaning of a modular architecture: compose a product from capabilities with clear responsibilities, then change one part while the rest of the lifecycle keeps its shape.
Change one module without rebuilding the platform
The shared core is made of independently deployable modules. Modules can be added or removed without downtime or a platform rebuild, so a new provider adapter, settlement route, distribution connector or servicing capability extends the same platform instead of creating a fork. The existing operating foundation stays available while the new configuration is introduced at its boundary. Our platform architecture explains how those ownership boundaries fit together.
Start with one product and its operating core
Consider an issuer offering a corporate note. An investor subscribes for €100,000 through the issuer’s investor portal. A bank receives the euro payment, a custodian arranges delivery, and an administrator or registrar updates the ownership register designated by the product’s legal setup.
The note’s operating core stays the same across those steps. Asset Passport keeps the instrument’s identity, terms, rights and supporting information together. Policy Compiler carries approved eligibility and transfer requirements into explainable decisions with versioned evidence. Torque Flow coordinates the durable transaction and the work that remains open. Settlement Intent states the asset, cash, parties, permitted route, delivery conditions and required confirmation. Asset Registry connects issued supply and representations to the authoritative ownership record.
The record does not stop when the subscription settles. Product Operations uses the same terms and holder records to coordinate coupon or interest payments, keep each distribution tied to the note, and carry the principal repayment obligation to maturity. An issuer can therefore operate a note through its full life instead of assembling a new process for issuance, servicing and repayment.
These are reusable capabilities working as one platform core. Policy and ownership are part of the product’s operating contract in every configuration; they are not optional attachments that a provider can replace.
Add choices around the same product
After the first note is operating, the issuer may add a second approved payment route. When both routes are part of the approved configuration, a second bank integration can handle euro settlement without changing the note’s identity, €100,000 obligation, coupon schedule or ownership record.
The shared core gives each route the same product context, lifecycle and ownership record. Each provider integration handles the details of its connection, so an issuer can extend the approved operating path without rebuilding the financial product. Adding that route leaves the platform available for the note and for other products already using the operating core.
The issuer can then extend access to an approved distribution channel or application surface. The same note can appear in a branded investor portal, an embedded journey or a partner application while each channel works from the same instrument and workflow. A team that needs more control can connect its application through APIs or the framework-free Torque SDK. A team that wants to operate its own application and deployments can choose IaaS; a team that wants a hosted branded experience can use white-label delivery. These choices change who owns the interface and surrounding operations, while the product’s policy, transaction and ownership records remain consistent.
The same separation applies to the financial infrastructure. Settlement Intent supports cash rails that differ by approved product configuration: conventional bank money, stablecoins or tokenized deposits, each with its specified currency and settlement conditions.
Configure custody and wallet or key-management arrangements around your institution’s operating model. A public or permissioned ledger can represent the instrument alongside the traditional register when the product and legal structure allow it. Asset Registry keeps those representations connected to the same official ownership authority rather than treating every ledger entry as a new issuance.
| Configuration choice | Customer benefit | Reusable core |
|---|---|---|
| Bank money, stablecoin or tokenized-deposit settlement | Choose a cash route that fits the product, investors and counterparties | Product terms, currency, settlement objective and transaction history |
| Custody and wallet or key-management arrangement | Match asset control to the operating model | Instrument identity, transfer rules and ownership authority |
| Traditional, public or permissioned ledger | Serve the records and digital channels required by the product | Asset Passport, Asset Registry and the same issued instrument |
| Hosted white-label, embedded/API/SDK or IaaS delivery | Choose how much interface and infrastructure the team operates | Policy framework, Torque Flow, Settlement Intent and servicing history |
Reuse the foundation across products
The second product does not have to repeat the first product’s platform construction. A fund has different terms and events from a corporate note: units rather than principal, valuation and dealing windows, subscriptions and redemptions, and a different distribution schedule. The shared capabilities still provide identity, eligibility, transaction coordination, settlement, ownership, servicing and evidence. The fund’s product definition and policies supply the differences.
The same principle applies when a provider changes. An adapter isolates a bank’s transport and authentication, a custodian’s delivery messages, an administrator’s register format or a ledger’s confirmation model. The provider can change at that boundary while the product’s policy, transaction identity and ownership history stay in the platform’s operating records. The replacement still needs mapping, testing and operational readiness; its work has a bounded place.
Independent extensions follow the same pattern. A CRM update, accounting entry or notification can react to a business event through a focused worker without adding downstream provider knowledge to every transaction service. The Cloud Run worker guide describes that extension model and its ownership boundaries.
Keep change deliberate
Modularity gives each choice a boundary; it does not make live financial actions interchangeable. A payment accepted by the first bank may need to finish there, or move through an explicit migration that preserves the operation identity, evidence and reconciliation. A new route or currency outside the product’s approved terms requires amendment and reapproval before use. A new provider cannot be treated as complete until its finality and records are checked.
Independent bank, custody and ledger systems also do not share a universal atomic transaction. Torque coordinates their obligations and keeps their outcomes visible, while each route supplies its own confirmation and recovery procedure. Legal terms, provider agreements, permissions and operational ownership still govern what a product can do. The Distribute Finance guide explains how those separate facts fit together.
Measure the next configuration
The commercial value of reuse appears in the next product, provider or channel. The team can start with existing integrations, workflow templates, policy framework and operating procedures, then focus new work on product-specific terms, route validation and delivery choices. Record the first configuration and compare the next one to show which foundations carry forward and which work is new.
The test is visible to every participant. The investor sees the same note and servicing history in the chosen channel. The operator can follow cash, delivery, ownership and coupon or principal obligations in one workflow. The engineer can add an approved route or delivery surface without rebuilding the product’s identity and history.
That is how one platform supports many configurations. The next note, fund, provider, ledger or channel builds on an existing operating foundation, so product teams can extend the business while keeping the financial record coherent.
