Deployment And Modules

Loci is designed to start as a hosted SaaS platform and expand as client requirements mature. Loci-hosted production infrastructure is the default deployment model. Dedicated and on-prem deployments are available when required by procurement, regulation, data residency, or client readiness.

Deployment Models

Hosted SaaS

Loci operates the production environment, platform services, upgrades, and core monitoring. This is the default path for most pilots and production rollouts.

Dedicated Environment

A client can run on a dedicated Loci-managed environment when isolation, residency, or operational policy requires it.

On-Prem Or Client-Managed

On-prem deployment is available for clients that need to host Loci inside their own infrastructure boundary. A SaaS tenant can transition to on-prem when the client is ready, subject to deployment planning and operating responsibilities.

Module Enablement

Loci modules can be enabled independently:

  • Transaction monitoring and MADIE evaluation.
  • Rules, FLM, and rule testing.
  • Alert queue and cases.
  • AccessGate device and session risk.
  • AccessGate AML screening and relationships.
  • Reporting and export workflows.

AccessGate and AccessGate AML are optional modules. Loci shows module-specific features only when the module is enabled for the tenant.

Integration Ownership

A typical deployment has shared responsibilities:

  • The client owns source system access, data correctness, and operational policies.
  • Loci owns platform APIs, evaluation, tenant configuration, and product workflows.
  • Both teams agree schemas, decision handling, environments, and rollout phases.

Where client systems cannot directly call Loci APIs, an integration adapter can translate source events into Loci's API contracts. The adapter can be delivered by Loci, the client, or a systems integration partner depending on the engagement.

Real-Time And Offline Workloads

Real-time transaction evaluation is designed to stay fast and reliable. Heavy workloads use separate paths:

  • Large reports and exports should run asynchronously.
  • Historical rule testing should be bounded and job-based for large date ranges.
  • Analytics should read from replicas or analytical stores where available.
  • Operational queues are designed to remain usable when a non-critical module is unavailable.

Environment Strategy

Use separate environments for:

  • Development and integration testing.
  • User acceptance testing.
  • Production.
  • Historical replay or load testing, when needed.

Rules should be tested while inactive before activation in production.