AccessGate AML

Real-time sanctions screening and compliance intelligence for financial institutions. Screen customers against global sanctions lists with second-degree relationship detection and AI-powered investigation tools.

Base URL: https://ag-aml.runloci.com

Why AccessGate AML?

Traditional sanctions screening matches names against lists. That's necessary, but not sufficient.

Modern financial crime operates through networks—shell companies, family members, associates. A customer might not appear on any sanctions list, but they're two steps removed from a designated individual. Traditional tools miss this.

AccessGate AML provides:

Sanctions Coverage

AccessGate AML aggregates and normalizes data from authoritative global sources:

Total coverage: 35,000+ entities with automatic daily updates.

Core Capabilities

1. Real-Time Screening

Screen customers, counterparties, and beneficiaries against all sanctions lists in a single API call:

curl -X POST https://ag-aml.runloci.com/v1/aml/screen \
  -H "X-API-Key: your-api-key" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Ahmed Mohamed",
    "entity_type": "individual",
    "include_related": true
  }'

Response:

{
  "decision": "CLEAR",
  "confidence": 0.95,
  "direct_match": false,
  "related_matches": [],
  "processing_time_ms": 45
}

Decision outcomes:

• CLEAR — No matches found, safe to proceed
• REVIEW — Potential match requires manual review
• BLOCK — High-confidence match, transaction should be blocked

2. Relationship Detection (Second-Degree Screening)

This is what sets AccessGate AML apart. The system maintains a relationship graph extracted from sanctions data, enabling detection of:

• Family members of sanctioned individuals
• Business associates and partners
• Owned/controlled entities
• Agents and representatives

Example: Screening "Amina Abacha" returns no direct hit—she's not on any sanctions list. But AccessGate AML detects she is the daughter of Sani Abacha (OFAC-sanctioned), flagging the transaction for Enhanced Due Diligence.

{
  "decision": "REVIEW",
  "direct_match": false,
  "related_matches": [
    {
      "entity_id": "ofac-12345",
      "name": "Sani ABACHA",
      "relationship": "daughter of",
      "relationship_type": "family_member",
      "source": "OFAC",
      "confidence": "stated"
    }
  ],
  "reason": "Related to OFAC-sanctioned individual"
}

Relationship types detected:

• family_member — Spouse, child, parent, sibling
• associate — Business partner, known associate
• owner — Owns or controls
• owned_by — Owned or controlled by
• employee — Works for
• agent_of — Acts as agent for
• linked_to — General connection

3. AI Agent Integration

The Agent Lookup endpoint is designed for AI/LLM integration, returning rich markdown context that language models can reason about:

curl -X POST https://ag-aml.runloci.com/v1/aml/agent/lookup \
  -H "X-API-Key: your-api-key" \
  -H "Content-Type: application/json" \
  -d '{
    "query": "Sani Abacha",
    "include_related": true,
    "format": "markdown"
  }'

Response includes:

• Markdown-formatted entity profile
• Sanctions programs and designations
• Known aliases and identifiers
• Related entities with relationship context
• Source citations for explainability

This endpoint powers the "Authority Compiler" pattern in agentic AI workflows—validating whether a proposed action is legally permissible before execution.

The Agentic Stack Pattern

AccessGate AML serves as the Authority Compiler in modern AI agent architectures:

┌─────────────────────────────────────────────────────┐
│  RETRIEVAL LAYER (RAG) - "The Librarian"            │
│  "Who is this customer?"                            │
└──────────────────────────┬──────────────────────────┘
                           ▼
┌─────────────────────────────────────────────────────┐
│  REASONING LAYER (LLM) - "The Analyst"              │
│  "Customer wants to send $50,000 to Nigeria"        │
└──────────────────────────┬──────────────────────────┘
                           ▼
┌─────────────────────────────────────────────────────┐
│  AUTHORITY COMPILER - "The Judge"                   │
│  ◀── AccessGate AML LIVES HERE                      │
│                                                     │
│  Checks: Direct sanctions? Related to sanctioned?   │
│  Output: PERMIT or COMPILATION ERROR                │
└──────────────────────────┬──────────────────────────┘
                           ▼
┌─────────────────────────────────────────────────────┐
│  EXECUTION LAYER (Tools) - "The Hands"              │
│  Only reached with permit                           │
└─────────────────────────────────────────────────────┘

The system provides deterministic, auditable compliance gates that AI agents cannot bypass.

Matching Intelligence

AccessGate AML uses multi-vector matching to reduce false positives while maintaining high recall:

Matching Techniques

Confidence Scoring

Each match includes a confidence score (0.0–1.0) based on:

• Match quality (exact vs. fuzzy)
• Multiple identifier matches (DOB, nationality, etc.)
• Relationship strength (stated vs. inferred)

Thresholds:

• 0.85+ — High confidence, likely same individual
• 0.70–0.84 — Medium confidence, requires review
• 0.50–0.69 — Low confidence, possible false positive

Fail-Closed Design

AccessGate AML operates on a fail-closed principle for high-risk transactions:

If sanctions data is stale (>24 hours old):

• Low-value transactions: Warning flag, allow
• High-value transactions: Automatic hold for review

This ensures compliance even during data ingestion failures.

API Reference

Screen Customer

POST /v1/aml/screen

Batch Screening

POST /v1/aml/screen/batch

Screen up to 100 names in a single request:

{
  "names": [
    "John Smith",
    "Jane Doe",
    "Acme Corporation"
  ]
}

Agent Lookup

POST /v1/aml/agent/lookup

Health Check

GET /v1/aml/health

Returns system status and data freshness for each source.

Integration Patterns

Pattern 1: Synchronous Screening

Screen at transaction time, block high-risk transactions:

const result = await screenCustomer(beneficiary.name);

if (result.decision === 'BLOCK') {
  throw new Error('Transaction blocked: sanctions match');
}

if (result.decision === 'REVIEW') {
  await flagForManualReview(transaction, result);
  return { status: 'pending_review' };
}

// Proceed with transaction

Pattern 2: Onboarding Screening

Screen during KYC with relationship detection:

const result = await screenCustomer(applicant.name, {
  include_related: true,
  dob: applicant.dob,
  nationality: applicant.nationality
});

if (result.related_matches.length > 0) {
  return { 
    status: 'edd_required',
    reason: 'Related to sanctioned individual'
  };
}

Pattern 3: AI Agent Compliance

Use agent lookup for LLM-powered compliance workflows:

const profile = await agentLookup(counterparty.name, {
  include_related: true,
  format: 'markdown'
});

const decision = await llm.evaluate(
  `Based on this sanctions profile, should we proceed with the wire transfer?
   
   ${profile.markdown_profile}
   
   Transaction: $50,000 to ${counterparty.name} in Nigeria`
);

Performance

Compliance & Audit

Every screening decision is logged with:

• Timestamp and request ID
• Input parameters
• Match details and confidence
• Decision and reasoning
• Data source versions at decision time

Audit logs are retained for 7 years and available via export API.

Next Steps

• AccessGate AML Integration Guide
• API Reference
• Relationship Detection Brief