Getting Started

Loci is the fraud-control intelligence layer between financial institution systems and fraud operations. Your application sends transaction and context data to Loci, Loci evaluates the event through the active control set, and your operations team monitors the resulting decisions, alerts, and cases.

Most deployments start with hosted SaaS. Dedicated and on-prem deployments are available when a client is ready to operate Loci inside their own infrastructure boundary.

1. Choose Your Initial Scope

Start with the smallest operational workflow that can prove value:

  • Real-time transaction monitoring for one or more payment rails.
  • A focused rule set covering high-value fraud typologies.
  • Alert queue triage and case investigation.
  • Optional AccessGate session or device risk for login and high-risk actions.
  • Optional AccessGate AML for sanctions, PEP, watchlist, and relationship screening.

AccessGate and AccessGate AML are optional modules. You can enable them later without changing the core transaction monitoring integration pattern.

2. Authenticate API Requests

Server-side integrations call Loci with organization credentials and an API key or token issued for that environment. Keep credentials out of browsers and mobile clients.

See Authentication for the current authentication pattern.

3. Send Transactions For Evaluation

Your backend sends each transaction to the transaction monitoring endpoint. Loci evaluates the payload against active controls and returns a decision that your system can use immediately.

http
POST /v1/transaction/{orgId}
Authorization: Bearer <token>
Content-Type: application/json

A typical response includes a decision, risk score, matched rules, and supporting evidence. The consuming application decides how to apply the response: approve, step up, queue for review, or block according to the bank's operating policy.

See Transaction Monitoring and Transaction Monitoring API Reference.

4. Create And Govern Rules

Rules are represented as FLM, the Fraud Language Model. FLM is Loci's explainable control format: it captures rule intent, signals, thresholds, aggregations, decision logic, and deployment state in a structure that can be reviewed by analysts and evaluated by MADIE.

Rules can be authored manually or with AI assistance, reviewed, tested while inactive, and then deployed when approved.

See Rules And FLM.

5. Test Before Activation

Inactive rule testing lets teams evaluate one or more inactive controls against manual payloads or historical transactions without affecting production decisions. This is the recommended path for tuning thresholds, validating control logic, and reducing operational noise before activation.

See Rule Testing API.

6. Monitor Alerts And Cases

When a transaction needs attention, analysts work from alert queues and can group related alerts into cases. Cases carry status, ownership, notes, timelines, dispositions, approvals, and linked evidence.

See Cases And Investigations.

7. Expand With Optional Modules

Once the core transaction monitoring loop is operating, many teams add:

  • AccessGate for device and session risk at login, onboarding, or sensitive actions.
  • AccessGate AML for sanctions, PEP, watchlist, whitelist, feedback, and relationship screening.
  • Custom data tables for client-specific lists, thresholds, exclusions, or reference data.
  • Reporting and exports through asynchronous workflows that do not burden online evaluation paths.

Production Checklist

  • Confirm the environment and organization credentials.
  • Confirm which modules are enabled for the tenant.
  • Agree the transaction schema and custom fields.
  • Decide how approve, review, and decline decisions are handled by the client system.
  • Configure initial active rules and inactive rules for test.
  • Confirm alert queues, case roles, and maker-checker approval policy.
  • Configure retention, audit, and export policies.
  • Run end-to-end tests with representative production-like payloads.