Skip to main content

Technical Reference

Architecture Overview​

The extensibility framework consists of several key layers:

  1. Extension microservices — Independent services that register point-based extensions. They provide metadata only (for example, extensionId, extensionPointId, remote, type) and do not communicate directly with the core banking platform.
  2. BFF layer — Aggregates all extension metadata from microservices and Experience Groups, returning a unified response to the frontend.
  3. Web platform library — The internal extensibility engine.
    • Extension Loader — Called during App Shell bootstrap. Fetches extensions from the BFF once at startup.
    • Extension Registry — An in-memory store holding all extension metadata. Acts as a central lookup system with no network calls at runtime.
  4. Common UI library — Owns the internal useExtensionPoint(extensionPointId) hook used by micro apps. It queries the registry and dynamically loads the required component or data object. On mobile, Module Federation is not supported; the platform uses ExtensionComponent with bundled extensions from @nxg-mobile/extensions.
  5. Micro apps / widgets — Define extension points in their code. When rendering, they call the hook, ensuring extensions load only where extension points exist.

High-Level Flow​

The diagram below provides a view of this process from extension registration to extension hosting:

CYO Overview

Extension Flow​

Phase 1 — Bootstrap (Once)​

When the App Shell starts, the platform fetches all extension metadata from the BFF. This metadata is stored in the in-memory Extension Registry. At this stage, extensions are known, but remote components have not yet been downloaded.

Phase 2 — Runtime (On Demand)​

When a micro app loads, it checks the registry for extensions mapped to its extension points. If an extension exists, it is dynamically loaded (via Module Federation on web) and either rendered or executed inside the micro app.

Extension Point Schema​

Extension payloads must conform to the JSON schema referenced by the extension point. This ensures validation is strictly enforced when extensions are registered.

FieldDefinition
extensionPointIdUnique, stable identifier for the extension point. Used in code and metadata to register and resolve extensions.
institutionIdIdentifier of the FI the extension point applies to. Omit for global extensions.
nameHuman-readable name or label for the extension point.
descriptionFunctional description of what the extension point does.
schemaReference to the JSON schema that validates extensions for this point. Defines the types and required properties.
info

Changes to extension point schemas are always backward compatible to ensure existing extensions continue to run.

Extension Metadata​

Extensions provide metadata to tell the platform how and where to load them. For a remote extension loaded via Module Federation, the metadata includes:

PropertyTypeDefinition
extensionIdstringUnique identifier for this extension.
extensionPointIdstringID of the extension point this extension registers to.
remoteobjectModule Federation descriptor; specifies how to load the extension.
remote.urlstringSource URL of the remote module.
remote.namestringRemote name (Module Federation name).
remote.entrystringExposed component or class name to load.
remote.categorystringLoader category (for example, ModuleFederation).

Contextual Data Contract​

Extensions receive contextual data from the platform at runtime. This contract ensures extensions remain loosely coupled, stable, and backward-compatible.

Contextual data allows extensions to:

  • Render UI conditionally
  • Apply FI-specific logic
  • Access account or transaction-level attributes
  • Construct dynamic URLs

The context does not expose internal platform state. All contextual data exposed through an extension point is rigorously reviewed and approved by the Security team to ensure compliance with privacy and data-handling standards.

The platform uses canonical models as standardized data contracts to pass contextual information (such as Account and Transaction) to extensions. FI developers should build against these canonical structures, as all contextual data provided to extensions adheres to this contract.

Choosing an Integration Point​

When registering an extension, select the integration point based on:

CriterionGuidance
LocationWhere the extension should appear (for example, Account History page, Transaction Details, Account Details)
FunctionalityUI rendering → use a UI extension point; data enrichment or configuration → use a data provider extension point
ContextEach integration point provides a specific data contract — see Extension Points

Important Notes​

  • An extension can only be registered against a valid and supported extension point ID
  • Each integration point may support one or multiple extensions, depending on platform configuration
  • The behavior and rendering of the extension are governed by the contract defined by the integration point
  • New integration points may be introduced over time

Mobile Limitations​

Mobile does not support Module Federation. Extensions are tightly mapped to their respective components in @nxg-mobile/extensions via ExtensionComponent.

Because of this mapping:

  • The application expects the exact extensionId to load an extension
  • Extension IDs cannot include arbitrary prefixes or suffixes beyond what the mobile bundle defines
  • The same extensionId cannot be shared across multiple FIs under the current extension management service implementation
warning

As a result, mobile point-based extensions can currently be onboarded for a single FI per extension ID, or a code change is required in the mobile app to support additional FIs.

Next Steps​