Frequently Asked Questions

3forge is the company behind 3forge Enterprise, an Application Fabric for building and operating real-time, data-intensive applications. The Application Fabric brings data access, event processing, application development and operational control together in one governed runtime. Instead of assembling separate products for messaging, databases, dashboards, entitlements, reporting and workflow logic, engineering teams build on a shared production-grade foundation and write only the logic specific to their business problem.

3forge was designed from first principles for financial institutions, where applications must process continuous streams of data, respond deterministically to events, enforce fine-grained entitlements and remain transparent under operational and regulatory scrutiny.

The Application Fabric is the 3forge architectural model for connecting data, logic, applications and execution across an enterprise estate that already exists. It virtualizes governed access to real-time and resting data, supplies the common runtime services required to build and operate applications, and connects users, workflows, analytical tools and AI agents through consistent interfaces.

The Application Fabric does not replace the enterprise technology stack. Existing databases, legacy systems, enterprise applications, Excel workbooks, notebooks and frameworks such as React remain in place and become participants in one observable, controlled environment. What makes an application part of the fabric is not where its interface is built, but how consistently it accesses data, invokes logic, enforces controls and exposes its operation.

The Application Fabric combines three capabilities that enterprises usually procure, develop and operate separately:

• Real-Time Data Fabric. Governed access across databases, streams, APIs, files and messaging systems, plus the caching, persistence, normalization, complex event processing and controlled distribution that operational workloads require.
• Application Engine. The recurring services applications need, including state management, event processing, permissions, forms, visualizations, reporting, testing, deployment and monitoring, so developers concentrate on business-specific logic.
• Operations Hub. Estate-wide visibility and control across deployed applications, components, dependencies, versions, licensing and workloads.

The pillars reinforce one another. Each connection, transformation, policy and application component created for one project becomes available for reuse, so every new use case strengthens the shared foundation rather than creating another isolated stack.

Not in the generic sense. 3forge is better described as a finance-native application engine. It includes visual development capabilities and fast UI composition, but its real value is that the runtime itself already includes the data, logic, governance and operational capabilities financial institutions repeatedly need. That makes it fundamentally different from a generic low-code tool or a standalone dashboard product.

Developers write explicit business logic and design bespoke workflows. The engine handles what is common, which is why 3forge describes the model as last-mile development.

3forge is deployed at Tier-1 investment banks, global hedge funds, asset managers, prime brokers, exchanges, private equity firms and sovereign wealth funds. Clients range from large sell-side institutions with thousands of users to lean buy-side firms that need to move fast without building infrastructure from scratch. Thousands of developers worldwide build on the platform.

Common use cases include trading desk applications, real-time risk and P&L, post-trade reconciliation, compliance monitoring, private capital fund operations and operational dashboards.

BI tools are designed for business analysts querying static or batch-refreshed datasets. 3forge is engineered for developers building applications on top of real-time streaming data, with sub-millisecond update latency, complex event processing and full programmatic control over every aspect of the system.

Unlike BI tools, 3forge is a complete development platform: it includes its own in-memory database, historical database, feed handler framework, scripting language (AmiScript) and a deployment model designed for 24/7 production environments in regulated industries. Tableau and Power BI can also act as consumers of the fabric through the 3forge ODBC driver, so the two are not mutually exclusive.

3forge is primarily deployed on-premises within client infrastructure, which is required by most institutional clients due to data residency, security and regulatory constraints. Private cloud and hybrid deployments are fully supported, including containerized environments running on Kubernetes.

Managed deployment options are available for select use cases. Contact us to discuss what deployment model best fits your environment.

3forge licensing is tailored to each institution's deployment scale and use case. Our commercial team works with you to structure an agreement that reflects the scope of your deployment, whether you are running a single business unit or a global, multi-region rollout.

Operationally, licenses are administered by the client through Operations Hub rather than through manual per-machine exchanges. See the Operations Hub & Licensing section for how license issuance, grace periods and offline deployments work.

Recent 3forge industry recognitions include:

• Prime Broker of the Year, Technology: HedgeWeek 2025
• Best Full-Stack Dev Platform: Trading Tech Insights Europe 2025
• Best Trading Tech Stack Platform: Trading Tech Insights USA Awards 2025
• Best Sell-Side Web-Based Development Environment: Sell-Side Tech Awards 2025
• Best Transaction Cost Analysis System Provider: Waters Rankings 2025

3forge is headquartered in New York at 225 Broadway, Floor 40, New York, NY 10007, with additional offices in Orlando, London, Singapore, Hong Kong, Tokyo and Toronto. General enquiries can be sent to info@3forge.com.

The Real-Time Data Fabric is the first pillar of the Application Fabric. It provides governed access across databases, streams, APIs, files and messaging systems while allowing source systems to remain authoritative, giving applications, users and agents unified, current-state access to real-time and historical tables, streams and procedures across the data nodes in the fabric.

It is not a new place to put data. It is a common operating layer over the repositories, streams and systems the enterprise already runs, adding the caching, persistence, normalization, complex event processing and controlled distribution that operational workloads need between a source and its consumers.

Real-time data is data in motion: market ticks, order and execution events, telemetry and messages arriving continuously from feeds, message buses and streaming platforms. Its value is highest at the moment it arrives, and it has no stable shape you can query later unless something captures it.

Resting data, also called data at rest or historical data, is data that has been written down: positions, reference and client data, prior trades, end-of-day records and long-term history held in databases, warehouses, lakes and files. It is stable and queryable, but it describes the past.

Most real business questions need both at once. "What is my exposure right now" is a resting set of positions revalued by a live price. "Is this algorithm behaving normally" is a live order flow compared against a historical baseline. Neither half answers the question alone, which is why 3forge treats the two as one operating model rather than two systems.

Data virtualization means giving consumers one consistent way to query, subscribe to and combine data without first copying it into a single physical store. The platform presents distributed sources through stable interfaces while managing source connectivity, normalization, entitlements, caching and workload control behind them.

The practical consequence is that a delivery does not have to wait for a consolidation program. Source systems stay authoritative and keep their own lifecycle, while the data they hold becomes operationally connected rather than physically centralized.

Because the two have fundamentally different engineering shapes, and a join has to reconcile all of them at once:

• Different access models. Resting data is pulled with a query that returns a finite result. Real-time data is pushed as an unbounded sequence of events. One is request and response, the other is subscription.
• Different notions of correctness. A historical query is repeatable. A streaming join has to define what "current" means at every instant, and decide what to do with late, out-of-order or revised messages.
• Different performance envelopes. A warehouse query measured in seconds cannot sit in the path of an event stream measured in microseconds.
• State has to live somewhere. Joining a stream to reference data means holding current state in memory, keeping it correct as both sides change, and doing so without unbounded growth.
• Entitlements must span both. A user permitted to see one desk's positions must see only that desk's live events too, enforced identically on each side.

Solving this inside each application produces duplicated and subtly divergent implementations. 3forge implements it once in the Center, where the in-memory real-time database, the historical database and the complex event processing engine sit in the same runtime and can be queried together within a single datamodel.

No. This is the "leave the data where it is" principle. Data should not be copied simply because a new application needs to access it. The fabric virtualizes access and presents distributed sources through consistent interfaces, policies and operational controls, while source systems remain authoritative.

The result is not a new central repository. It is a common operating layer across the repositories, streams and systems the enterprise already uses, in which real-time and historical data remain physically distributed but become operationally connected.

3forge virtualizes access across databases, feeds, APIs and legacy systems so teams work with them through one governed layer. Real-time and resting datasets can be queried, joined, enriched and operationalized together without forcing every workflow to rebuild integration logic from scratch.

Virtualization alone is not sufficient for operational workloads, so the fabric adds a functional layer between source and consumer: caching to protect underlying systems and reduce latency, persistence for later analysis, normalization and enrichment across sources, and filtering, conflation or business rules applied to live events before distribution.

The same governed information can be delivered to applications, AI agents, Python processes, APIs, reports, dashboards, PDFs or Excel, without creating a separate integration path for each consumer.

This matters because enterprise platforms now serve a far broader range of consumers than people reading reports. Services, models, agents and automated workflows consume data continuously, each with different access patterns and performance requirements, and each one that builds its own integration adds another set of connections, transformations and access controls to maintain.

Traditional data governance focused on users, databases and reporting environments: access granted by identity and role, with catalogs, lineage tools and audit systems documenting how information is stored and used. That model becomes harder to apply as the number and variety of consumers grows. Applications access several sources on behalf of a user. Services run continuously without direct human interaction. Agents select tools dynamically, issue a sequence of queries and produce outputs that feed other systems.

3forge founder and CEO Robert Cooke has described the risk directly: "there is now suddenly this lack of governance over how things are tested and around how things are being built, how things are connected."

Governance therefore cannot rely on controlling access at the perimeter of each database. It must extend across the full path through which data is requested, transformed, distributed and acted upon, and it must be observable, so teams can see which consumers use which sources, how data moves through applications, where policies are enforced and when behavior changes. Added after the fact, every new consumer becomes an exception to manage. Made a property of the layer through which data is accessed, it is inherited by everything built on top.

Agents and automated workflows consume information more frequently, combine a wider range of sources and may initiate actions without waiting for a user to navigate an application. At the same time, AI-assisted development increases the number of applications, services and interfaces an enterprise has to govern and operate.

The platform must therefore understand who or what is making a request, which information it may access, what operations it may perform, how much load it may place on a source and where its outputs may be sent. These policies have to apply consistently whether the consumer is a person, an application, a Python process or an agent. An agent should not receive a parallel route around the controls established for users and applications.

No. Warehouses and lakes are destinations: data is moved into them and queried there. The Real-Time Data Fabric is an access and processing layer that sits across the systems an institution already runs, including its warehouse or lake, which typically becomes one more governed source.

The fabric does hold data where that serves an operational purpose. The Center keeps current state in an in-memory database and can persist selected history in its own historical database, and frequently requested information can be cached to protect the underlying system. But the objective is not to become the single copy of record. Large enterprises will continue to use different technologies for different workloads, and source systems must often remain authoritative.

An application engine is a shared runtime that standardizes the common infrastructure every serious application needs: connectivity, security, state management, monitoring and lifecycle control. 3forge applies that idea specifically to financial institutions. Instead of rebuilding the same plumbing for every risk tool, operational monitor or reporting workflow, teams build on one finance-native runtime that already understands real-time data, deterministic behavior, entitlements and auditability.

An application engine defines how software runs, not simply how it is written. It manages the movement of data, the scheduling of processes, the allocation of resources, the handling of failures and the lifecycle of the application.

Game engines such as Unity and Unreal provide rendering, physics, animation, input handling, networking, asset management and deployment as a shared runtime, so developers concentrate on the mechanics, content and experience that differentiate their game. Enterprise application development has the same recurring structure: most operational applications need connectivity, state management, concurrency, event processing, authentication, entitlements, workflow, visualization, reporting, monitoring and deployment.

3forge implements those concerns once, at the engine level, and applies them consistently across every application built on it. As more applications adopt the engine, connections, controls, components and operational practices are reused rather than recreated. This is the principle of last-mile development: the engine handles what is common, developers concentrate on what must be different.

When teams build directly on the fabric, the Application Engine provides approximately 95 percent of the technical foundation required, including state management, event processing, permissions, forms, visualizations, reporting, testing, deployment and monitoring. Developers focus on business-specific logic and interaction.

Applications built on the fabric use the same data, transformations, entitlements and processing logic without creating another integration layer, and they move into a controlled production runtime in which dependencies, activity and performance are observable by design.

Organizations evaluating how to build financial software generally encounter three approaches, each with a different trade-off between speed, flexibility, control and long-term sustainability:

• Buy a vendor solution. Fastest path to initial functionality when requirements closely match what the product supports. Customization is often limited, integration can be complex, and the roadmap depends on the vendor. Best used when the workflow is not a differentiator.
• Build in-house. Maximum flexibility and ownership, but the team designs, builds and maintains every layer of the stack, which increases cost, delivery risk and operational burden. Best used for the core business differentiator.
• Leverage an application engine. A shared, production-grade runtime with reusable primitives tailored to the domain, combining the control of a custom build with the leverage of a platform. Best used to facilitate the core business and drive the differentiator.

These describe the main capability areas of the 3forge Application Engine. Live Data refers to governed access across real-time and historical data plus event-driven processing. Live User Interface refers to the front-end layer for dashboards, forms, pivots and workflows. Live Workbench refers to the browser-based environment for building, testing, diagnosing and operating applications. Live Scripting refers to the runtime-native business logic layer used to encode calculations, transformations, callbacks and reusable application behavior.

LivePivots™ and Live Prompting extend the same model to real-time pivot analysis and natural-language interaction.

No. Dashboards are one visible output of the platform, but 3forge is better understood as an application runtime. It supports data integration, event processing, workflows, reporting, operational tooling, governed data access and full user-facing applications. Reducing 3forge to visualization alone understates the architecture and makes the platform sound much narrower than it is.

The Center can already deliver headless, server-side applications that operate at the core of the fabric without any user interface at all, which is where the name Application Fabric comes from. The Web Server adds the ability to produce real-time interfaces on top of those flows.

Enterprise platforms are rarely deployed successfully through technology expertise alone. In the forward-deployed engineering model, 3forge platform specialists work directly with business and technology teams on a concrete operational use case, learn from the implementation and adapt the solution around the realities of the organization.

The first use case serves two purposes: it delivers a working application, and it establishes connections, data models, controls, components and operating practices that can be reused. The objective is not permanent dependence on external engineers, it is to accelerate the first implementations and transfer knowledge to internal teams.

3forge frames enterprise data and application problems as four connected challenges rather than four separate programs:

• Bridge real-time and historical data. Make distributed live and resting data available through one consistent operating model, without forcing consolidation into a single repository.
• Build production-grade agentic applications. Provide the recurring technical capabilities as part of the platform so AI-assisted prototypes can become software that is governed and operated in production.
• Govern data at enterprise scale. Extend entitlements, lineage, policy enforcement and audit across the full path through which data is requested, transformed, distributed and acted upon, for people, services and agents alike.
• Connect data, logic and execution. Reduce the brittle handoffs between observation, decision and action so a signal can be detected, evaluated, approved and acted upon in one operating flow.

AmiCore is the governed runtime container at the center of the 3forge architecture. It provides the common environment in which 3forge components are configured, executed, monitored and governed, and it applies cross-cutting controls across data access, business logic, user interaction and external interfaces.

Every AmiCore instance includes services in three areas: runtime control (deployment, configuration, resource management, orchestration, health monitoring, instrumentation), security and governance (login and authentication, role-based access, audit, file-system management, port management, plugin control) and access and interoperability (native data access plus REST, MCP and JDBC interfaces).

No. AmiCore is not a substitute for a Docker container, virtual machine or Kubernetes pod. AmiCore operates inside the Java Virtual Machine, which may itself run directly on an operating system or be packaged within a Docker image and managed through Kubernetes or another infrastructure platform.

The distinction matters: the outer infrastructure controls where the process runs and which physical resources are available to it, while AmiCore controls how the Application Fabric operates inside that process. This is what extends governance beyond deployment and into the runtime itself.

Purpose-built components run inside the AmiCore container:

• Relay. Integration and transport layer at the boundary with external systems.
• Center. Principal data and event-processing component, holding the real-time database, the historical database and the complex event processing engine.
• Gateway. Governed distribution layer presenting a distributed Center estate through one logical interface.
• Web Server. Application runtime for user interaction, workflows, reporting and execution.
• Web Manager. Centralized store for application layouts, user profiles and preferences across multiple Web Servers.
• Web Balancer. Platform-aware entry point that distributes user sessions across Web Servers.

Operations Hub then provides the estate-wide view across all deployed instances.

The Relay sits at the boundary between 3forge and external systems. It brings live data and requests into the fabric and carries commands or processed information back toward external destinations, connecting to real-time feeds, messaging systems, databases, files and local applications through feed handlers and adapters.

As information arrives, the Relay can parse, validate and transform it before routing it to one or more Centers. Routing rules can determine which messages go to which Centers, replicate selected streams to several destinations or discard messages that do not meet defined criteria. The Relay also provides guaranteed messaging and store-and-forward for workloads that cannot tolerate data loss during interruptions.

The Center is the principal data and event-processing component of the Application Fabric. It consumes live information arriving from Relays and other components, then represents the current state of that information in an in-memory SQL database so applications can query continuously changing data using a structured model.

Alongside the real-time database, the Center provides a historical database designed for very large on-disk datasets, so current state and long-term history participate in the same fabric. The Center also includes a complex event-processing engine in which database-native triggers aggregate, filter, join, enrich and transform information as source tables change.

The Gateway is the governed distribution layer. As the fabric expands across multiple Centers, applications, agents and external integrations connect to a single Gateway interface through which they query data, subscribe to streams and invoke procedures, without needing to understand the physical topology.

The Gateway can present multiple underlying tables as one virtual table, several sharded streams as one subscription and distributed procedures as one callable service, enabling query map/reduce across a distributed fabric. It also caches common query results and state snapshots, consolidates overlapping subscriptions and fans them out, and allows Centers to be added or removed without a restart. Secure transport, authentication compatibility, role-based access and access journals apply at the interface.

The 3forge Web Server is where data and logic become a working application. It connects users to real-time and historical information through interactive tables, forms, trees, charts, maps, pivots and other components that can accept user input, invoke server-side logic and initiate controlled actions.

Because the Web Server is part of the same runtime as the data and processing layers, the interface stays closely connected to application state, live updates are delivered directly to the browser, and entitlements determine what each user can see and do. The same application model also produces scheduled or event-driven email and PDF reports using the layouts and logic already used by the live application.

The Web Manager centralizes application layouts, user profiles and preferences, then supplies the right information to whichever Web Server is handling a particular session. This means a user does not receive different dashboard settings because a session was routed to another server, and application teams do not synchronize layout files manually across every Web instance.

The Web Balancer distributes users across multiple Web Servers, providing a platform-aware entry point so each application does not implement its own distribution logic. Together they allow the web tier to support thousands of concurrent users without making each Web Server an independently managed environment.

No. AmiCore provides a common runtime but does not prescribe a single deployment topology. For a small use case, several components may run together within one JVM, which reduces the number of processes to configure and gives a direct route from integration to processing and presentation.

As workloads grow, components can be separated by function: Relays placed close to data sources, Centers distributed for processing capacity or resilience, Web Servers added for more concurrent users. Components can also be divided by business area, geography, security boundary or environment. The result is neither a conventional monolith nor a collection of unrelated microservices, but a componentized runtime composed according to the requirements of the estate.

Yes. AmiCore supports a plugin model so institutions can add approved integrations or specialized capabilities through controlled extension points. This allows the runtime to adapt to local requirements without turning every extension into a modification of the core platform.

The container therefore serves two purposes: it provides the native services required by the platform, and it establishes the controlled boundary within which the platform may be extended. Plugin management itself is one of the governed container services.

The 3forge Historical Database (HDB) provides columnar historical tables capable of holding trillions of rows, persisted to disk, supporting partitioning and queried with the same SQL syntax as real-time tables. Published capacity is more than 10 trillion rows and more than 1,000 columns.

HDB supports large column counts and heavy data types such as blob fields, schema management that adds, drops or modifies columns without impacting historical partitions, row-level UPDATE and DELETE clauses that preserve partition optimization, and archiving of real-time data from streaming updates using event, batch or timer-driven approaches. Data from historical tables can also be loaded into a real-time table where the full breadth of query optimizations, including joins, becomes available.

Storage type is configurable per column, and the system dynamically adapts storage types during optimization on a partition basis for disk efficiency and query speed based on actual data usage:

• FLAT. Fixed-length types such as INT, FLOAT and DOUBLE.
• VARSIZE. Variable-length types such as STRING and BINARY, up to 1 TB.
• BITMAP. Efficient for low-cardinality strings.
• PARTITION. Organizes rows into isolated partitions.

Partition columns are immutable, so schema design deserves careful planning up front. HDB maps older partitions to new schemas seamlessly, preserving historical integrity.

The Center provides database-native triggers so business logic executes on the fly as data updates. Combined with conflation, these triggers process only as much work as needed. The following are supported out of the box:

• Aggregation to create and update aggregation tables.
• Projection for filtered tables.
• Join to create joined tables.
• Decorate to enrich data with additional data from another table.
• Relay for sending messages through the 3forge Relay.
• AmiScript to run custom scripts upon any insert, update or delete activity.

Centers use several techniques to balance transmission speed against technical constraints:

• Delta-based processing. Only changes are handled rather than reprocessing or retransmitting the entire dataset on each update.
• Conflation. When replicating across the tiered architecture, Centers can send every update or only the latest one on an agreed interval, discarding intermediate values and reducing downstream burden.
• Summarization. Regular and delta-based summary metrics such as averages, sums, counts, minimums and maximums compress data volumes and support time-based analytics.
• Decoration. Event-driven triggers enrich, validate and propagate data in response to table-level changes.

3forge supports major enterprise environments across Windows, Linux, Apple platforms and Android. Browser support includes Chrome, Firefox, Edge and Safari. It also supports Docker and Kubernetes, a range of cloud providers, common source control systems and desktop container environments used on financial desktops. For connectivity, 3forge supports a broad set of databases, APIs, messaging systems and feed handlers.

The 3forge ODBC driver and Excel RTD Server are currently designed for 64-bit Windows clients.

3forge ships with more than 35 database adapters and 15 feed adapters, so it can consume real-time and resting data from virtually any source and present it as a single access point to data consumers. Centers and Relays can both connect directly to databases; Relays are additionally designed to connect to real-time feeds.

Once data is in 3forge, it can be queried via REST API, JDBC, ODBC and MCP, as well as through bidirectional libraries in .NET, Python, Java, WebSockets and gRPC.

Supported database adapters, available to both Centers and Relays, include:

• Relational and warehouse. Oracle, Microsoft SQL Server, MySQL, PostgreSQL, Sybase, SybaseIQ, IBM DB2, Snowflake, Greenplum, HP Vertica, Netezza, Impala, Hive, SQLite, MemSQL, SingleStore, Phoenix.
• NoSQL, cache and in-memory. MongoDB, Couchbase, Redis, Apache Ignite, Hazelcast, HBase, Chronicle Queue.
• Analytics and specialist. KX, Apache Spark, Hadoop, Deephaven, Symphony, R, Fred, Quandl, Bloomberg.
• Files and services. AMI DB, flat file, AMI Shell, Excel, REST API.

Custom adapters can be implemented through the published Java plugin API.

Supported feed handlers, available to Relays, include Kafka, Solace, Tibco, RabbitMQ, ActiveMQ, IBM MQ, Amazon SQS, Aeron, 60East AMPS, Chronicle Queue, KX Stream, gRPC and FIX. Market data feeds include Bloomberg BPIPE, QuantHouse and OneTick.

Because the Relay parses, validates and transforms messages at the integration boundary, source-specific logic does not have to be reimplemented downstream.

Centers, Relays and Gateways expose a common set of programmatic access libraries: REST API, JDBC, ODBC, .NET, Python, Java, WebSockets, gRPC and MCP.

Providing these within the runtime creates consistency between interfaces. A consumer should not receive fundamentally different governance simply because it connects through JDBC rather than REST, or because an action is initiated by an agent rather than a user.

Yes. 3forge ships with dedicated Bloomberg integrations: BPIPE for real-time market data subscriptions (introduced in Summer 2024) and the Bloomberg Datasource Adapter for access to historical and reference data (introduced in Fall 2024). Both are supported out of the box as licensed Bloomberg clients.

Yes. 3forge is fully compliant with the FDC3 2.0 standard for interoperability between financial applications, and is routinely deployed on enterprise-grade browsers and desktop containers including Here (formerly OpenFin) and Interop.io. Finsemble callbacks were added in the Summer 2023 release.

This matters for firms that need 3forge applications to participate in broader desktop workflows through context sharing and intent handling, rather than operating in isolation.

Yes. 3forge supports gRPC for connecting microservices (added in Spring 2025) and exposes a REST API Server that makes database data and monitoring information accessible to external systems. Outbound REST calls can also be made from AmiScript for event-driven integrations, and the Relay can invoke local processes or send commands to downstream applications.

Minimum requirements vary by workload. A development instance runs comfortably on a modern laptop with 16 GB RAM. Production deployments at Tier-1 banks routinely run on high-memory servers (256 GB to 1 TB RAM) to accommodate large in-memory datasets.

Because 3forge is a JVM-based system, heap sizing, GC tuning and CPU core count are the primary performance levers. Our solutions engineering team will advise on sizing during the onboarding process.

Yes to all three. 3forge is designed to support deployment across on-premises, cloud and hybrid environments while fitting into existing operational practices. Components can be distributed, scaled and configured according to workload, resilience, security and geographic requirements.

This allows firms to start with a focused deployment and expand the fabric as more applications, data sources and users are brought onto the platform, rather than committing to a full-estate architecture on day one.

Yes. 3forge is distributed as a Docker image and is fully compatible with Kubernetes-based orchestration. This includes support for horizontal pod autoscaling, resource limits, persistent volume claims for the 3forge Historical Database, and integration with cluster-level secrets management for credentials.

Operations Hub does not replace Kubernetes or deployment automation. It supplies the application-aware inventory and evidence needed to govern those processes.

A base 3forge environment can be stood up in hours. Most clients have a working prototype integrated with their internal data sources within days to weeks, depending on the complexity of the data pipeline. Full production rollouts, including security integration, SDLC workflows and user acceptance testing, typically complete within a few weeks.

3forge solutions engineers provide hands-on implementation support throughout the process.

The best starting point is a 30-minute demo with a 3forge solutions engineer. We tailor the conversation to your specific use cases, data environment and team structure, so you can evaluate fit quickly and move toward a proof of concept on your own infrastructure.

Use the "Get in touch" button on any page, or reach out directly through our contact page.

LivePivots™ is the 3forge approach to turning pivoting into a live operational capability rather than a static spreadsheet exercise. It allows users to slice large datasets into dynamic categories across hundreds of columns and millions of rows, apply filters and permissions, and work with both real-time and historical data in one governed interface.

The key point is not just that users can pivot data, but that they can do it at scale, with entitlements, and inside live workflows where the pivot updates dynamically as underlying data changes.

Guaranteed messaging in 3forge ensures that every critical update is durably persisted and delivered reliably regardless of system load or transient network conditions. Messages are journaled to a write-ahead log (WAL), allowing downstream Centers, including those temporarily offline, to recover and replay missed data upon reconnection.

Guaranteed messaging does not perform duplicate suppression, and it should not be described as exactly-once delivery. It provides the durability and continuity required for real-time trading, risk and compliance systems. Being precise here matters because technical buyers will notice overclaims.

3forge Relays support dynamic routing rules that dispatch messages to specialized processing Centers based on content, load or custom logic, all configurable in real time. Each Center can independently process its portion of the workload before results are merged through a map-reduce operation.

This architecture supports parallel processing and high-performance aggregation across distributed systems, and it is one of the mechanisms by which a 3forge deployment scales horizontally without redesigning the application.

Yes. 3forge includes message transformation capabilities that allow firms to inspect, modify, enrich or filter messages in flight without writing custom code, using declarative rules and scripting.

This is especially valuable for FIX and other financial protocols, where dynamic adjustments may be required to support different counterparties, normalize formats, redact sensitive fields or route based on content.

3forge provides data replication between primary and warm standby Center databases through simple configuration. The standby checks the health of the primary and can take over on failure with all data already loaded in memory.

Replication can also be used for load balancing between multiple Centers based on routing rules in the Relay, increasing both redundancy and scalability. The architecture supports more advanced deployments including multi-region and global replication.

Yes. 3forge produces automated PDF reports and email reports using the same live layout model and logic as the user interface, so there is no separate reporting product and no duplicated presentation logic.

Reports can be tailored to each recipient and can include charts, tables, heatmaps, pivot grids and aggregation tables. Content, formatting, signatures and distribution rules can be varied by role or workflow, which suits trading performance reviews, risk analyses, client-facing materials and regulatory documentation.

The pyami-3forge package provides a purpose-built interface between Python and the Application Fabric. It allows Python processes to query current and historical data, subscribe to live Center updates, publish information through the fabric and interact with authorized AMI services, without connecting independently to each underlying source.

Because access is mediated by the fabric, it can be associated with a workload identity rather than personal credentials embedded in a notebook, and Python activity can be attributed, restricted to authorized data and included in the operational and audit view of the platform.

• Real-time client. For queries, publishing, Center subscriptions and incremental updates.
• Python DB-API 2.0. For applications built around the standard PEP 249 connection and cursor model, including parameterized queries, batch operations and stored procedures.
• SQLAlchemy dialect. For SQLAlchemy Core and ORM expressions, schema reflection and pandas integration.
• Pure-Python JDBC client. For lightweight query-to-DataFrame access where the native real-time extension is not required.

The choice of interface does not change the underlying operating model. Python still reaches data through AMI rather than establishing independent connections to every database, feed or warehouse.

Yes. The real-time client can subscribe to one or more Center tables. A subscription begins with the current snapshot and then delivers row-level additions, updates and deletions as incremental events, so Python code reacts to changes without repeatedly polling the server or rerunning an entire query.

Queries and subscriptions can be combined: a process may load an initial historical or reference dataset through SQL, then maintain the current portion of its state through live Center updates. The real-time client also supports asynchronous SQL, so a long-running query can be submitted without blocking the main workflow.

Python workflows often begin in Jupyter notebooks that depend on local files, personal credentials, copied data or direct access to a source system. Moving that work into production usually means reconstructing its connectivity, permissions, monitoring and operating model.

The 3forge Python package provides the same fabric interface across exploratory and operational environments, so a developer can begin in Jupyter and then use the same access model in a scheduled script, analytical pipeline, AI workflow or long-running service. The surrounding Python code still needs to be tested and hardened, but its connection to enterprise data does not need to be replaced.

3forge supports Excel through two complementary paths. The ODBC driver lets Excel query the fabric through Power Query as though it were a conventional relational database, browsing tables and loading or transforming data before it enters the workbook. The 3forge RTD Server uses Excel's native Real-Time Data function to subscribe individual cells to fields published by a Center, so values update automatically as the Center sends incremental updates.

This lets users keep the applications and working methods appropriate to their role while data access remains connected to one managed AMI environment.

Each formula identifies an AMI cluster and a specific field on an object within an AMI table:

• =RTD("AmiRtd.Server", , "<cluster>", "<table>.<object_id>.<field>")
• =RTD("AmiRtd.Server",,"N1","Trades.AAPL.price")
• =RTD("AmiRtd.Server",,"N1","Trades.AAPL.volume")

Until the first matching update arrives the cell displays #N/A, then shows the latest value and continues to refresh as the Center publishes changes. Cells watching the same table share a reference-counted Center subscription and cells requesting the same topic share one cached value, so a workbook can contain many live formulas without creating duplicate upstream subscriptions.

ODBC and RTD address different consumption patterns, and many Excel deployments use both:

• ODBC uses a request-and-response model suited to result sets: browsing tables, running SQL queries, retrieving historical or current records, and refreshing on demand. Examples include positions, reference data and history.
• RTD uses a subscription model suited to selected live values that update continuously. Examples include prices, statuses and limits.

A workbook might use ODBC to retrieve a larger working table, then use RTD to update selected prices or operational measures continuously, with Excel formulas combining the two.

The 3forge ODBC driver presents AMI tables through the standard Windows ODBC interface, so Excel, Tableau, Power BI, LibreOffice Base, Python through pyodbc, PowerShell and applications written against the C or C++ ODBC API can query the fabric as though connecting to a conventional relational database.

This allows an institution to expose one managed query surface instead of building a separate connector for every analytical or reporting product. The driver is intended primarily as a query and analytical interface: it operates in autocommit mode and does not support transaction boundaries through commit or rollback.

ODBC connections can use SSL/TLS, with mutual TLS required when secure AMI JDBC listeners are used. The client presents its certificate to the server, and the server may also be pinned through its public key. Connections can include an ordered list of failover endpoints, and the client library retries with controlled backoff if the primary AMI server is unavailable. The RTD Server uses the same mutual-TLS model.

Both interfaces are currently designed for 64-bit Windows clients. The ODBC driver ships as a Windows machine installer that registers with the Windows ODBC Driver Manager and requires administrator rights. The Excel RTD Server ships as a per-user installer that registers the COM component for the current user and does not require administrator rights.

AmiScript is the native programming language of the Application Fabric. It provides one model for working across data, logic, workflows and presentation, combining familiar concepts from Java, Python, SQL and string templates while adding functions and data types intended for financial systems.

Because the language operates throughout the fabric, logic does not need to be rewritten as it moves between layers. A calculation can begin in the data model, be reused within a workflow and appear directly in a user interface or report, and the same logic can be called by an external application or an AI agent through an authorized interface.

AmiScript includes more than 1,500 built-in functions organized into domain-specific libraries, so developers assemble sophisticated workflows without re-implementing common primitives. Categories include:

• Mathematics, trigonometry, rounding, binary and encoding operations
• Date, time and timekeeping, including nanosecond timestamps
• Statistics, averages, percentiles, clustering and resampling
• Financial measures such as beta and percentage change
• String manipulation, formatting, parsing (including JSON and XLSX) and concatenation
• Cryptographic signing, colorimetry, randomness and URL handling
• Operational functions such as logging and session control

AmiScript adopts Python-inspired syntax for defining maps, lists and nested structures, so complex financial objects such as market data snapshots, pricing ladders, risk buckets and configuration objects can be expressed inline without verbose class definitions or external schemas. JSON is well supported throughout the Application Engine.

Because these structures are first-class citizens in the language, they can be passed directly into calculations, visual components or persistence layers without transformation. The same structure can feed pricing logic, populate a table or drive a chart, which eliminates glue code between data modeling and execution.

Yes. AmiScript supports strongly typed, overloadable function definitions that encapsulate business logic deterministically. Functions can be defined once and reused across scripts, queries, models and visuals, ensuring critical financial calculations remain consistent throughout the system.

This matters in finance, where notional value, exposure, margin or PnL must be calculated identically across risk, trading, reporting and compliance workflows. Because functions execute inside the governed runtime, they are observable, auditable and subject to the same controls as the rest of the system.

AmiScript integrates tightly with AmiSQL, so developers execute parameterized queries against named data sources using familiar SQL constructs while remaining inside the entitlement, auditing and lineage framework. Placeholders such as ${USERACCOUNT} are resolved at runtime, allowing one script to adapt automatically to different users or sessions without hard-coding identifiers.

Because data access is embedded directly in the scripting layer, there is no artificial separation between querying data and operating on it. Results can be reused immediately for downstream computation, visualization or persistence, and computed values can be embedded into tables, charts, tooltips, dashboards and reports through built-in templating.

SQL familiarity is helpful but not required for every development task. 3forge uses a SQL-like query language for datamodels, and developers fluent in SQL will feel at home. The Data Modeler provides a visual workspace that abstracts much of the query construction, lowering the barrier for teams less experienced with query languages.

For complex event processing, joins and streaming aggregations, deeper SQL understanding will improve development speed and result quality.

Yes. 3forge integrates into commonly used IDEs such as Visual Studio Code through dedicated plugins, so developers work with fabric projects alongside the source code, repositories, testing tools and review processes their teams already use.

Communication between the IDE and the fabric is backed by Model Context Protocol. Through this interface the development environment can inspect the capabilities exposed by the runtime, retrieve context such as schemas, procedures and runtime objects, and invoke permitted development functions. The same governed tools are available whether the next change is written manually or suggested by an AI assistant.

No. 3forge layouts are built and run from a browser window, and engineers switch from User mode to Editor mode with one control key. There is no need to compile an executable, publish changes to the back end, refresh the front end or deploy the software. Engineers see the impact of changes immediately, in the same window where they develop.

Exploratory changes can remain transient until they are explicitly saved, which supports rapid iteration without immediately altering the stored layout.

• Nested panels with navigation components, horizontal and vertical tabs, and multiple levels of nesting.
• Dividers with snap for precise control over dashboard arrangement, and transient panels for context-sensitive views and pop-ups.
• Dynamic HTML for custom content presentation and rich interactivity.
• Advanced charts combining bars, scatters, lines, areas, maps, trends, heatmaps, canvasses, radial and 3D charts that update in real time.
• Aggregation tables with column groups, advanced filters and cell-level editing.
• Real-time pivot tables across hundreds of columns and millions of rows, and real-time tree tables with customizable hierarchies and formulas.
• Dynamic styling and theming including light, dark, high-contrast and brand-directed palettes that update on the fly.

Common visualizations include grouped bar charts, multi-line charts, transpose tables, pivot tables, CRUD tables, breadcrumb filters, heat maps, 3D charts, area charts and Sankey diagrams.

3forge supports ADA adherence through keyboard-based navigation across complex dashboards, keyboard-based column filtering for tables and trees, and scripting support for panel navigation and focus. Layouts also support high-contrast themes.

Layouts are fully responsive and work on mobile devices. Because 3forge is highly optimized to reduce data transmission volumes, it delivers large datasets to mobile browsers in real time, so executives can monitor key indicators, track risk exposure and receive alerts from a browser-based mobile UI.

Yes. Developers can create fully custom components using AmiScript and the platform's form framework. Custom web-based components can also be embedded through external panel support. For teams with specific visualization requirements, such as custom charting or specialized trading UI elements, the platform provides the hooks needed to integrate third-party libraries or proprietary components.

Yes. 3forge has built-in Source Control Management integration (introduced in Winter 2020), enabling versioning of layouts, datamodels and scripts. This integrates with Git-based workflows and supports standard SDLC practices including branching, merging and code review.

The platform also supports SDLC hooks that let teams enforce promotion policies, from development through UAT to production, without leaving the 3forge environment.

Yes, concurrent development on the same layout is supported as of the Spring 2025 release. The built-in Merge Tool allows multiple developers to make changes independently and reconcile differences before promotion, in a way that understands the AMI layout hierarchy rather than treating the layout as raw XML or configuration text.

Development happens inside a browser-based environment that combines data modeling, query analysis, AmiScript development, layout construction, debugging and operational inspection. Teams define data models, build dashboards and workflows, write business logic, create event-driven processing and manage source-controlled changes from one environment.

Because the runtime and the development environment are the same system, a change can be written, executed and observed against live conditions without a compile, publish and redeploy cycle. The goal is not just faster UI building, but faster end-to-end application delivery.

Datamodels are generally best for per-user, query-driven shaping of data, while realtime tables are generally best for shared, delta-driven state across many users. This distinction matters for scale and architecture. Teams should avoid using per-user models for globally shared hot state when a realtime table would be more appropriate.

The Workbench is a browser-based IDE included inside the AmiCore governed runtime. It provides immediate access to the data, components and logic available within the current environment, subject to the user's entitlements, so developers can explore data, execute queries, inspect application objects, test logic and debug behavior without first reproducing the environment elsewhere.

Because the Workbench operates inside the runtime, it exposes information that is difficult to reproduce through an external editor alone: live state, execution flow, values and how a procedure interacts with the surrounding application. It is particularly useful during initial development, operational investigation and collaborative work with business specialists.

No. The Workbench does not replace source control or the institution's software-development lifecycle. It provides immediate coverage of the platform, while external IDEs support the broader engineering process alongside repositories, testing tools and review workflows.

The Workbench also supports continuous integration workflows, cross-platform consistency across modern browsers, and device-agnostic responsive output.

Yes. Within the Workbench, help is built directly into the development flow rather than being a separate destination. As developers type commands, functions or expressions, the Workbench surfaces available parameters, expected types, return values and usage patterns in place.

Because the help system is driven by the same underlying model that executes the logic, it reflects the exact syntax, capabilities and constraints of the environment in real time.

The Data Modeler is the visual workspace for defining how data is accessed, transformed, combined and delivered to an application. Developers connect databases, files, real-time feeds and other sources, then use SQL and AmiScript to filter, join, calculate, aggregate and blend the result into reusable datamodels.

It also shows dependencies between data sources, datamodels, application panels and relationships. Developers can test queries, inspect results and errors, parameterize models using application variables or user selections, and configure execution behavior such as startup processing, automatic refresh, conflation, timeouts and result limits. Unlike a traditional entity-relationship tool, the Data Modeler represents the operational data-processing layer of an application.

Yes. The 3forge inline debugger runs inside the Workbench. Breakpoints can be placed against individual lines of AmiScript, and scripts can be launched in debug mode from the same interface in which they are written. When execution reaches a breakpoint, the Debugger panel displays current variables and the call stack, and execution can be continued through subsequent breakpoints.

Because the debugger is integrated into the environment, AmiScript callbacks can be executed and tested directly against a connected 3forge instance using live or test data. This is especially valuable for event-driven applications, where logic may be invoked when a layout loads, a data model runs, a user interacts with a field or table, or underlying state changes.

The DB Shell is the interactive command interface for querying, configuring and administering the Center database, executing AMI SQL with a familiar MySQL-like syntax. Users can retrieve and modify data, create or alter schemas, and manage Center objects such as tables, indexes, procedures, triggers, timers, derived views and custom database objects.

It also provides inspection tools: SHOW exposes the objects currently running in the Center, DESCRIBE returns the AMI SQL required to reconstruct an object, and DIAGNOSE reports operational information such as table memory consumption. The Shell can also be accessed via Telnet and SSH with a more limited feature subset.

The F1 Console is the command-line administration and diagnostic interface for a running AMI Web instance. Through an authenticated connection to a dedicated console port, administrators inspect active users, logins, Web sessions, loaded layouts and session activity without going through the graphical interface.

It exposes the resources used by each session, including datamodel executions, errors, processing duration, generated tables, real-time feeds, processors, panels and memory consumption, and supports operational actions such as terminating sessions or logins, creating headless sessions and executing AmiScript within a selected session. Where the DB Shell focuses on the Center database, the F1 Console focuses on the AMI Web runtime.

The Merge Tool is the graphical interface for reviewing, combining and resolving changes made to an AMI layout by multiple developers. Rather than comparing raw XML or configuration text, it interprets changes in the context of the application's structure, recognizing windows, panels, datamodels, scripts, settings and visualizations.

Differences are presented as a navigable tree comparing the original shared layout, the developer's own changes and changes saved by others. Individual modifications can be accepted, rejected or combined, conflicts are identified with a proposed resolution where possible, and the merged result can be previewed and tested in AMI before saving.

3forge frames AI around governed adoption rather than generic AI enablement. The platform provides real-time governed data access, a resilient runtime, entitlement-aware control and observability, so firms can scale AI without bypassing controls, duplicating legacy complexity or creating opaque access paths to sensitive data.

The underlying position is that AI-generated code does not remove production responsibilities such as identity, permissions, state, concurrency, errors, retries, testing, deployment, monitoring and auditability. In many cases it increases them by producing more code and more services. The sustainable approach is to provide those recurring capabilities as part of the platform so developers and agents concentrate on business-specific logic.

3forge exposes a governed development and data-access surface through the Model Context Protocol. Rather than connecting an AI assistant directly to each database, API or message stream, the institution exposes selected platform capabilities through the Application Fabric.

Depending on the tools made available and the identity of the user, an authorized assistant may retrieve documentation, inspect components, explore schemas, construct and execute AMI SQL queries, review logs or invoke authorized runtime operations. The MCP connection does not create a parallel route around platform controls: available data, procedures, components and actions remain subject to the authentication, entitlements, deployment policies and audit controls applied by the governed runtime.

The 3forge MCP plugin provides first-class support for Claude Code, Codex and GitHub Copilot, with generated integrations for Gemini and Cursor. This allows development teams to work within familiar coding environments without designing and maintaining a separate set of 3forge prompts and instructions for every assistant.

Through one common interface, multiple assistants work against the same controlled surface. The institution defines what the environment exposes, while developers use the coding tools that fit their established workflows.

For Claude Code, the plugin provides direct commands for common development activities:

• 3forge-init establishes the project context.
• 3forge-plan prepares an implementation plan.
• 3forge-query supports data exploration and AMI SQL queries.
• 3forge-runtime interacts with the connected instance.
• 3forge-review reviews an implementation or proposed change.
• 3forge-debug assists with runtime and application investigation.

These commands are entry points into the same underlying skills and MCP tools rather than separate access paths.

A basic MCP connection gives a compatible assistant access to the tools and information exposed by the runtime. The 3forge MCP plugin adds a development model around that connection, equipping AI coding tools with reusable 3forge skills, specialized development agents, guided workflows and conventions for interacting with a running instance.

The plugin combines two kinds of knowledge and keeps them deliberately separate. Stable development instructions describe how to approach activities such as planning an application, constructing a query, modifying a layout or investigating a runtime issue. Environment-specific knowledge is retrieved from the connected instance, including documentation, deployed components, exposed tools, schemas, logs and runtime capabilities. As the deployment evolves, the assistant adapts without every detail being embedded permanently in the plugin.

The plugin includes a library of skills covering application authoring, data access, runtime interaction, configuration, review and debugging. A skill gives the assistant a structured method for a particular type of task, such as inspecting a Center schema before constructing an AMI SQL query, working with an application layout using supported panel patterns, or investigating a runtime issue using configuration and log information.

For larger requests, specialized development agents divide the work: one may inspect the running environment, another construct the query, another organize the layout, another review the proposed implementation. The agents do not create separate forms of authority. They operate through the tools, documentation and permissions made available to the original coding assistant.

Yes, where authorized. Through MCP the assistant can discover the components available in the connected environment and identify the tools associated with each one, then direct a request to the component responsible for the relevant data, application or runtime function. Global tools provide platform-wide documentation, logs and common capabilities, while component-specific tools expose the functions of individual runtime components.

This closes an important gap in AI-assisted development. A model reasoning only from source files may produce code that is syntactically plausible but disconnected from the actual deployment. The assistant receives only the tools and information exposed to its identity, and its runtime activity can be governed and audited through the fabric.

3forge maintains a structured knowledge corpus for AI development, containing reference documentation for the functions exposed through MCP together with reusable patterns showing how those functions combine to query data, build applications, work with layouts and interact with the runtime. The corpus is organized by functional domain so the assistant receives guidance relevant to the task at hand.

3forge inventories the live MCP tool surface and audits the related documentation and patterns against the implementation, checking whether exposed functions are covered and whether documented names, parameters, syntax, configuration keys and behavior remain accurate. The audit does not modify platform source or accept its own documentation changes: it produces a reviewable difference and an audit report, preserving a human approval step. When a claim cannot be verified, it is escalated for manual review rather than resolved through inference.

The 3forge MCP plugin follows a document, verify, apply model. Before proposing a platform change, the assistant consults the relevant 3forge documentation and development patterns, and where a validation tool is available it checks the proposed implementation before attempting to apply it.

This does not make every AI-generated change automatically correct. It creates explicit stages at which assumptions can be identified, syntax tested and invalid changes rejected. Where the platform function supports it, generated work can remain staged or transient until a developer explicitly applies or commits it, so layouts and panels can be explored and refined during a session without every intermediate action becoming a permanent change.

Ask AI is the 3forge chatbot embedded directly in the 3forge Web environment, so users work with data and applications through natural language without moving between the operational interface and a separate AI tool. Because the conversational interface sits inside the application, it can use the context already available to the user.

Its effective authority is determined by the user's identity and entitlements, the tools made available to the assistant and the policies configured by the institution. It does not receive unrestricted access to underlying databases, components or applications. For analytical use cases it can translate a natural-language request into AMI SQL, and it may be configured read-only or, with appropriate authorization, given access to selected data-definition or data-modification functions.

Depending on the user's permissions and the institution's configuration, the chatbot can:

• Answer natural-language questions using data available through the fabric.
• Construct and execute AMI SQL queries.
• Interact conversationally with 3forge applications and workflows.
• Invoke explicitly authorized runtime functions.
• Delegate tasks to specialized platform agents.
• Use agents and instructions created for institution-specific applications.
• Work with configured AI models and providers.
• Retain and continue user conversations across sessions.

Yes. The institution selects the AI models and providers permitted for use. Where several models are configured, users may be allowed to select the appropriate option from within the conversation.

Administrators also control which tools the assistant may invoke, whether conversations are retained, and how many actions or delegated steps may be performed during a request. These limits help prevent an open-ended conversation from becoming an uncontrolled sequence of runtime operations. Conversation history may be retained per user, allowing an investigation to continue across sessions while preserving attribution.

They are complementary routes into the Application Fabric. MCP allows external coding assistants and AI tools to interact with the fabric through a standard interface, and is primarily suited to developers and agents working from coding tools, IDEs and external automation systems.

Ask AI provides the embedded experience for users working directly within a 3forge application, bringing natural-language access to the same operational environment where the data, workflows and user context already exist. Both reduce the need for direct source connections, copied data and application-specific AI integrations, and both keep AI interaction inside the identity, entitlement, instrumentation and audit model of the fabric.

Yes. Agents access data through governed pathways, inherit permissions, and can be logged, monitored and controlled centrally. An agent should not receive a parallel route around the controls established for users and applications: it enters the runtime through a defined interface, receives only the context and functions it is entitled to use, and leaves an attributable record of its activity.

Governance is therefore not added to each application after development. It is inherited from the environment in which the application runs.

Published 3forge Center figures:

• Historical database capacity: more than 10 trillion rows
• Historical database columns: more than 1,000
• Real-time database throughput: more than 2 million operations per second
• Real-time database latency: under 100 microseconds

Actual figures in a given deployment depend on hardware, schema design, concurrency and workload shape.

Two market data reference points. The consolidated feed for US equity trades and quotes (the SIP) carries roughly 2.5 billion messages per trading day. If one row is one consolidated SIP message, 10 trillion rows represents about 4,000 trading days, or roughly 16 years.

Options market data is far denser, at roughly 200 billion quote updates per day on OPRA during active markets. Even at that rate, 10 trillion quote updates would represent about 2.5 months of options quote traffic.

Yes. STAC, a technology-research firm that benchmarks new technologies under workloads relevant to financial institutions, independently tested and confirmed that 3forge Web exceeds the real-time performance of traditional heavyweight front ends.

Peter Lankford, STAC's Executive Director, said: "We found that on average, the system responded with charts of 2 million data points in roughly 3.7 seconds. We also found that as 25,000 records representing 700 thousand database fields streamed into the system every second, the system made new records available for user queries in less than 150 milliseconds on average."

3forge is deployed at institutions with thousands of concurrent users across 24/7 global operations. The Web Balancer and Web Manager provide horizontal scaling of the web tier as native components, without relying on third-party infrastructure. Specific user capacity depends on dashboard complexity and the number of active subscriptions per session.

End-to-end latency from market data receipt to UI update is typically in the single-digit millisecond range for standard deployments. For latency-sensitive workflows such as options pricing or execution monitoring, the in-memory architecture eliminates the overhead of round-trips to external databases, which is where most competing solutions introduce delays.

3forge also supports nanosecond and microsecond timestamp granularity for precise latency measurement and broker-level analytics.

Several mechanisms keep the browser responsive as data volumes grow:

• Server-side processing. Calculations are offloaded to Centers and the Web Server returns only relevant results such as aggregated figures, preserving bandwidth and front-end responsiveness.
• Visible-data transmission. Datasets underlying charts, tables and pivots are held in the Web tier and transmitted to the browser only when visible on screen.
• Real-time propagation. When one element on a UI changes, 3forge propagates that change intelligently across related data sets and views so the UI stays coherent as complexity increases.

The 3forge Historical Database is purpose-built for storing very large time-series and event datasets on disk with fast on-demand query performance, using the same SQL syntax as real-time tables. It integrates directly with the Center, so historical and real-time data can be queried together within a single datamodel, eliminating the need for a separate data warehouse layer.

Column-oriented layout, per-column storage strategies, partitioning and sort indexing make it cost-effective at very high data volumes. Schemas can be altered instantly without backfilling data.

No. Scaling the web tier is handled natively by the Web Balancer: no external load balancer or service mesh is required, though they can be used if your infrastructure policy requires it. Data tier scaling is achieved by adding Center nodes under replication, with no dependency on external caching or messaging layers for core functionality.

Gateways can also be configured to call other gateways to scale efficiently across data centers and regions, and Centers can be added or removed without restarting the Gateway.

The architecture expands in several directions without changing its operating model. More Relays can be placed near new sources, more Centers introduced for processing, storage or regional resilience, Gateways added for consolidated access, and Web Servers added as the user population grows.

A deployment can scale vertically by assigning more resources to an instance, horizontally by adding instances, or functionally by separating components with different performance and availability requirements. The fabric is not defined by one physical layout, it is defined by the consistent roles, protocols and controls that remain in place as the layout changes.

Yes. Depending on deployment design, resiliency patterns can include hot-hot or hot-warm Center replication, multiple Web components, web balancing and distributed user profile management. For messaging continuity, 3forge supports journaling and replay so downstream components recover missed data after reconnecting.

Recovery should be discussed in the context of the specific deployment architecture rather than as a one-size-fits-all checkbox.

In an HA deployment, Center state is continuously replicated to a warm standby node that checks the health of the primary and can take over on failure with all data already loaded in memory. Feed handlers reconnect and resume subscriptions, allowing the in-memory dataset to stay current.

For use cases requiring full historical persistence across failures, the 3forge Historical Database provides durable on-disk storage that survives node restarts.

Yes. The replication architecture supports multi-region and global deployments. This is commonly used by institutions operating across New York, London, Hong Kong and other financial centers where each region requires both local performance and cross-region consistency. Advanced replication mechanisms for the Center were introduced in the Summer 2022 release.

The Python and ODBC clients also support distributed deployments, with ordered failover endpoints and automatic reconnection when the active endpoint becomes unavailable.

3forge integrates with enterprise key management systems such as HashiCorp Vault and CyberArk, enabling real-time key access without storing sensitive credentials on the server. Passwords and connection strings are retrieved dynamically at runtime and never persist on disk within the 3forge deployment. This capability was introduced in the Winter 2021 release.

The licensing model is designed to avoid turning temporary connectivity issues into production outages. If an instance cannot reach Operations Hub at startup, it may continue using its last license for a configurable grace period.

For environments without a license server, 3forge can issue a standalone license sealed to a local host and verified at every startup. No server and no network are required for that process to complete.

Authentication is extensible via industry-standard Single Sign-On protocols, including full support for SAML 2.0 and OAuth 2.0, allowing integration with identity providers such as Okta, Azure AD and Ping Identity.

Because authentication is provided at the AmiCore container level, it applies across the deployment rather than being confined to an individual application module. A REST request, JDBC query, user action or MCP invocation enters through a different interface while remaining subject to the same identity, entitlement and audit model.

Yes. Authorization is enforced through a granular Role-Based Access Control framework, with policy definitions supporting nested roles, group hierarchies and data-level entitlements. Permissions can be applied down to the field or cell level, ensuring strict segregation of data visibility across users and teams.

Entitlement filtering is enforced at the query execution layer, so it cannot be bypassed from the UI. This is essential for multi-desk deployments where different trading desks or regions must have segregated views of shared data.

Yes. All data, whether at rest or in motion, is protected via end-to-end encryption: TLS for transmission and AES for storage, with secure replication protocols ensuring consistency and integrity across distributed deployments.

The 3forge integration with enterprise KMS systems ensures encryption keys are managed externally and rotated according to your security policy.

Yes. 3forge is SOC 2 Type 2 certified by the AICPA.

3forge also undergoes security assessments as part of vendor due diligence at Tier-1 financial institutions. A security documentation package including architecture diagrams, penetration test summaries and data handling policies is available to clients under NDA during procurement.

Some financial institutions and government organizations operate under CISO-level policies that mandate strict guarantees about what code can execute, how data can be accessed and how behavior is audited. Lockdown mode is a system-level configuration that enforces those guarantees:

• File system. Read, create or modify only within predefined, protected paths.
• Ports and sockets. No arbitrary sockets or network access.
• Java libraries. No loading of custom Java packages.
• UI layouts. No JavaScript injection, so only code controlled by the engine runs.

By enforcing that only code crafted inside 3forge can run, lockdown mode delivers complete audit coverage and entitlement enforcement over every file, port, library and external data interaction.

Yes. 3forge logs user actions, authentication events and data access at a configurable level of granularity, and the Gateway keeps access journals of all interactions. Audit logs can be exported to your firm's SIEM, log aggregation platform or compliance archival system.

This supports internal audit requirements as well as regulatory obligations under MiFID II, FINRA and similar frameworks.

Infrastructure governance usually works from the outside inward: it determines which software may be deployed, where it may run, which resources it may consume and which network zones it may enter. AmiCore adds governance from within the application runtime.

It authenticates users and services, associates them with roles, and applies those roles to the data, procedures and application functions they may access. It also manages runtime concerns such as file-system access, network ports, plugins, component configuration, resource allocation and monitoring. This matters most when AI agents become participants in enterprise workflows, because the same controls apply regardless of which interface a request arrives through.

Operations Hub is the estate-wide control layer for a 3forge deployment. It is a client-hosted application that catalogs deployed 3forge applications and their instances, monitors their health and utilization, identifies versions, manages licensing and generates alerts and reports.

Where AmiCore governs what occurs within each runtime, Operations Hub records where those runtimes are deployed, how they are performing, which versions they use and whether they are operating within their licensed scope. The result is a live inventory linked to operational evidence rather than a manually maintained list of what teams believe has been deployed.

No. Operations Hub operates entirely within the client environment and does not require a direct connection from the deployed estate to 3forge infrastructure.

Operations Hub gathers health and usage information from registered AmiCore instances with component-level granularity. At the runtime level this includes CPU, memory, thread counts, garbage collection, user logins and active sessions. It can also drill into telemetry inside the AmiCore container, including open ports, partitions, open files and OS-level signals.

Rolling averages, highs and lows over different time periods provide a basis for identifying sustained capacity requirements and emerging trends rather than reacting to isolated measurements. Alerts and scheduled PDF reports can be directed to the teams responsible for particular product areas or regions.

The monitoring model also looks for absence and inconsistency. If an expected instance stops checking in, Operations Hub can flag that the service may be stalled, disconnected or no longer operating as recorded. If an unregistered instance or an out-of-scope request appears, the discrepancy is surfaced before it becomes an inventory, licensing or audit problem.

This complements rather than replaces infrastructure monitoring. Conventional tools may show that a host or JVM is consuming memory. Operations Hub adds the 3forge context: which application is running, which components it contains, where it is deployed, which version it uses and how its sessions and licenses are behaving.

Operations Hub establishes a structured inventory around the application rather than treating every process as an unrelated record. An application is registered once with its business area, description and permitted regions, and its running instances roll up to that application record with details including environment, region, host, status, JVM and installed components.

This makes version differences visible across the estate, so technology teams can identify which instances have moved to a supported release and which remain on an earlier version. Upgrade planning becomes a defined list of affected applications and instances rather than an investigation conducted for each release.

Operations Hub centralizes license issuance and inventory. A parent key supplied by 3forge allows the institution to generate and manage child licenses internally. Licenses are associated with registered applications, product areas and regions rather than being permanently locked to an individual host.

When an approved instance starts, it declares itself to the license server and receives a machine-level license automatically, with each grant recorded. This is the only time the license server is called: on subsequent startups the key pair is validated locally and the instance starts on its own, fully offline. Usage can be reviewed by application over daily, weekly and monthly periods.

Yes. 3forge can issue a standalone license sealed to a local host, naming the application, permitted hosts and validity dates, which is verified locally at every startup. No server and no network are required for this process to complete.

Where a license server is used, a local trusted admin creates a secret key on the 3forge Client Portal that delegates authority to issue local machine licenses, bounded to specific hostnames, applications and an expiry. A grant is meaningless on its own: it counts only while stapled to the original 3forge document.

Where Operations Hub delivers top-level telemetry across the fabric, each component is fully instrumented for granular investigation across code execution, data access, latency and throughput:

• Flame thread analysis. Performance profiling that visualizes how execution time is distributed across functions, exposing slow code paths precisely.
• Advanced log viewer. Purpose-built visualizations that analyze application logs to describe JVM memory allocation, consumption and headroom based on messages processed in queues, with generated observations to guide analysis.
• End-to-end latency analysis. Latency measured and correlated from event timestamps through processing stages down to individual packages, presented in live layouts that surface trends, outliers and performance drift.
• Per-session and per-application resource attribution. The Workbench attributes resource usage within a single JVM to individual users and applications, making it possible to detect imbalances, protect execution time for critical users and identify which applications drive load.

3forge publishes major named releases approximately three to four times per year, aligned with seasonal cadences. Each release includes new features, performance improvements and bug fixes. Patch releases addressing critical issues are made available on an as-needed basis between major releases.

Release notes for 3forge Enterprise are published on the 3forge portal at portal.3forge.com/release-notes.htm. A summary of each release is also available on our Release Notes page.

Upgrades are designed to be backward-compatible with existing layouts and configurations. The standard process involves deploying the new 3forge binary in a staging environment, running your existing application suite through acceptance tests, and then promoting to production. The 3forge support team can assist with upgrade planning for complex environments.

Operations Hub supplies the application-aware inventory that makes upgrade scope explicit, showing which instances are on which version across the estate.

Yes, maintaining backward compatibility is a core commitment at 3forge. Existing AmiScript, layouts and datamodels continue to function across version upgrades. When behavioral changes are introduced, they are clearly documented in the release notes with migration guidance. Deprecated features are typically supported for multiple release cycles before removal.

3forge projects should be managed with normal software engineering discipline. Layouts and relevant configuration should live in source control, and deployments should be promoted through at least development and production, ideally with a QA or UAT stage in between.

Teams should validate full built dashboards and supporting configuration in lower environments before promotion, rather than treating a layout export by itself as production-ready.

Yes. The Workbench allows developers to edit, execute and test AmiScript callbacks directly against a connected 3forge instance, using live or test data, before changes are committed to the layout definition or promoted to a higher environment.

Transient object support means exploratory code changes do not affect the stored layout until explicitly saved.

The Center includes testing and code coverage tools that analyze which code was invoked, including runtimes, alongside a debugger with breakpoints and intuitive error codes for stepping through custom logic.

A query planner pre-compiles and plans execution for optimized performance, which is useful when validating that a datamodel behaves as intended under production-shaped data.

Yes. Most clients operate at least three environments: development, UAT and production. The 3forge source control integration and SDLC hooks are designed to support promotion workflows between these environments. Layouts and configurations are stored as files that can be versioned and promoted using standard CI/CD pipelines.

Testing should cover code correctness, data availability, entitlements, performance under load and deployment behavior. For data models and application logic, teams should validate not only whether code compiles, but also whether datasource assumptions, schema assumptions and refresh behavior are correct.

Strong 3forge testing includes inspection of intermediate results, validation of user-specific entitlements, and promotion testing in lower environments before release.

Dedicated 3forge engineers provide 24/5 support during the trading week, so teams can resolve issues quickly and continue building. Beyond standard support channels, 3forge offers product documentation, release notes, certification and project de-risking services.

3forge can also help with technical assessments, implementation guidance, architecture questions and structured intervention for high-pressure or underperforming projects. 3forge is not only a software platform, but also a delivery partner when needed.

Full technical documentation, including the AmiScript reference, component API, configuration guides and architecture diagrams, is available at doc.3forge.com. Documentation is updated with each release and includes searchable API references, tutorials and worked examples.

More than 25 hours of structured tutorials guide teams from fundamentals to advanced production patterns. A formal certification program is available in partnership with Mallon Associates.

3forge also provides structured onboarding delivered by solutions engineers, covering AmiScript development, datamodel design, feed handler configuration and production deployment best practices, on site or remotely.

3forge includes a built-in monitoring console exposing runtime metrics: memory usage per table, subscription throughput, query execution times and JVM heap statistics. Column memory analysis tools help identify inefficient data schemas, and the REST API makes monitoring data accessible to external observability platforms such as Grafana or Datadog.

Operations Hub adds the estate-wide view, and component-level tooling such as flame thread analysis, the LogViewer and end-to-end latency analysis supports deeper investigation. For complex production issues, the 3forge engineering team engages directly through the support channel.

Yes. Active clients have access to the 3forge developer portal and knowledge base, which includes searchable Q&A, common patterns and recipes, migration guides and community-contributed examples. Client engineering teams also participate in a shared Slack community where 3forge engineers are active and available for technical discussion.

3forge supports three delivery models, and the same production-grade runtime, tooling and governance framework applies to all of them:

• 3forge Builds (turnkey delivery). 3forge assumes full responsibility for designing and delivering the application to defined requirements and timelines.
• Your Team Builds (autonomous build). Internal teams design and deploy independently using public documentation, tutorials and support.
• Both Build (hybrid model). 3forge Forward Deployed Engineers embed with your teams, blending internal ownership with specialized acceleration.

Because the platform is an application engine rather than a black-box product, firms can move between these models over time without compromising architectural consistency.

In the turnkey model, 3forge works to a managed project structure with clearly defined scope, milestones and deliverables, and regular checkpoints that provide transparency and executive oversight throughout the lifecycle.

Delivery leverages the full application engine, including pre-built primitives for data integration, entitlements, real-time processing, UI composition and operational tooling. The final system is delivered fully configured to your infrastructure, branding, identity management and entitlement framework. It is a production-ready deployment, not a prototype. This model suits situations where speed, clarity of ownership and guaranteed execution are paramount.

In the hybrid model, 3forge specialists operate within your development workflow, contributing architecture guidance, production patterns and performance optimization expertise. Your institution maintains architectural control and domain ownership while benefiting from engineers who have deployed the platform across diverse production environments.

Hands-on collaboration ensures knowledge remains inside your organization: developers gain practical coaching and best-practice guidance while building real systems rather than abstract examples. This model maximizes velocity while preserving institutional knowledge and long-term autonomy.

Yes. Because 3forge is well documented, internal teams can design and deploy independently. The platform is built for technical practitioners, with comprehensive public documentation at doc.3forge.com, more than 25 hours of structured tutorials, a certification program in partnership with Mallon Associates, and 24/5 engineering support during the trading week.

This model suits organizations with strong internal development capacity that want to institutionalize expertise.

3forge Enterprise is normally introduced into an existing data estate, and the deployment strategy follows from the need it addresses. Common entry points:

• Accelerating a new application. Connect required sources in place and expose them through governed interfaces so the application team focuses on business logic instead of connectors, caching, entitlements and monitoring.
• Productizing analytics or AI. Preserve analytical work in Excel, Python or Jupyter while changing how it reaches enterprise data and production processes.
• Connecting fragmented applications. Provide the fabric between tools that already work individually but do not pass data, state and decisions consistently between them.
• Introducing AI-driven applications safely. Put a governed access layer between quickly built applications and enterprise systems, replacing temporary APIs and direct database connections.
• Stabilizing a project under pressure. Insert 3forge selectively to take responsibility for the parts of a system that are preventing delivery, while preserving what already works.

Yes. When a project is already delayed or unstable, restarting from a new architectural foundation usually creates additional risk. 3forge can be inserted selectively to take responsibility for the parts of the system preventing delivery: unreliable data movement, missing real-time state, duplicated business logic, slow interfaces, incomplete monitoring or workflows that span too many systems.

Because the stabilizing layer is itself production-ready, the immediate intervention can become part of the long-term fabric rather than another temporary solution that must later be removed.

• Technology assessment framework to quantify requirements based on strategy complexity, asset classes traded, volumes and expected growth.
• Implementation checklists covering data integration, risk system configuration, regulatory reporting setup and trading connectivity.
• ROI calculation tools quantifying productivity gains, reduced operational risk and total cost of ownership comparisons.
• Solution architecture templates for common fund configurations across strategies such as multi-manager, systematic and credit-focused.
• Client workshop materials, vendor evaluation scorecards, implementation roadmaps and a governance and best practices guide.

3forge supports a spectrum of builders, but not every task requires the same skill level. Some users focus on dashboard construction or querying, while more advanced users handle scripting, event processing, data modeling and plugin development. The platform is accessible to multiple technical profiles, while some capabilities are intended for engineers or technically strong platform teams.

3forge is used across trading and front office, risk management, regulatory adherence, portfolio management, private equity, data integration and data orchestration. Specific workflows include consolidated order books, real-time reconciliations, FX transaction cost analysis, treasury repo and dividend ladders, real-time credit limit monitoring, trade anomaly detection, algorithm monitors and kill switches, CAT reporting, intraday factor attribution, carried interest and waterfall computation, golden record assembly and data warehouse caching.

Clients have built more than 500 distinct use cases in finance on the Application Fabric. The value compounds when a firm uses one engine across multiple workflows rather than buying or building each one separately. See use cases for detail.

Yes. The 3forge solutions engineering team provides hands-on implementation support, from initial architecture review and data model design through to production go-live. For clients with specific delivery timelines, 3forge can embed engineers within the client team to accelerate development. Our enterprise services offering covers ongoing strategic and technical support beyond initial deployment.

AI is now a shipping part of the platform rather than a future roadmap item. Current capabilities include the governed MCP interface, the 3forge MCP plugin for AI coding tools, specialized development agents, the embedded Ask AI chatbot and an audited knowledge corpus for model-facing documentation.

3forge continues to expand the ways users, developers, services and agents interact with enterprise data while maintaining the identity, entitlements, workload controls, observability and auditability required in production. Specific roadmap details are shared with clients through our product briefing program.