FastPort Connect

Executive Summary

FastPort Connect is a middleware orchestration platform purpose-built to sit between DISA's three core fulfillment systems — DISA Screen, DISA Works, and D360 — and any employer-facing interface. It exposes a single unified REST API and a modern employer dashboard, routing all underlying transactions to the appropriate DISA system, aggregating results in real time, and issuing portable FastPort Number (FPN) credentials that workers carry across employers on the network.

FastPort is not a CRA. DISA remains the Consumer Reporting Agency of record for all background and drug test results. FastPort handles orchestration, routing, tenant isolation, and the modern client experience only.

Current Build State — What Is and Is Not Live

Enterprise technical reviewers expect a clear-eyed current-state disclosure. The following table is our transparent assessment. Items marked BUILT are production ready — externally curl-verifiable with test receipts on file. Items marked DESIGNED are architected and sequenced — your inputs and the commercial agreement are what unlock the build. Items marked PILOT are live in a controlled pilot environment.

Platform Architecture

FastPort Connect is a multi-tenant, multi-layer platform. Each layer has clear separation of concerns and hardened isolation boundaries between tenants. The following diagram represents the production target architecture.

API Gateway Layer

All inbound traffic enters through the API Gateway, which enforces:

• Authentication — API Key (X-FastPort-Key: fp_live_…) or OAuth 2.0 client credentials with 3,600-second bearer tokens. Keys stored as PBKDF2 hashes — raw key never persisted.
• Per-tenant rate limiting — configurable burst + sustained limits per API key; 1,000 req/min (API Key) / 5,000 req/min (OAuth). Keys cryptographically bound to tenant_id. Returns 429 + Retry-After.
• Idempotency key store — duplicate order submissions return cached responses, never double-submit to DISA.
• TLS 1.3 termination — cert-pinning enforced on the DHS E-Verify connection. No HTTP fallback in production.

CRA Routing Engine

The routing engine is the architectural core that makes FastPort CRA-neutral. It resolves which downstream system fulfills each check type on a per-client, per-check basis. Routing rules are stored as configuration, not hardcoded logic, which means:

• A new CRA can be added by back-end configuration — no client-side changes.
• Per-client routing overrides allow a client to prefer one CRA over another for specific check types.
• Circuit breaker logic detects CRA degradation and fails over to a configured alternate (where available).

Storage Layer

• PostgreSQL — primary datastore; tenant_id on every table; Row Level Security (RLS) policies enforce hard isolation at the database layer. Append-only audit log (no UPDATE/DELETE permitted via RLS). Validated in pilot environment 2026-05-15.
• Redis — job queues for async screening workflows, response cache for hot-path lookups, rate limit counters. Redis in-process cache available for basic deployment, dedicated Redis service for pilot, HA Redis cluster targeted for full production scale.
• Amazon S3 — document storage (I-9 forms, background reports); AES-256-GCM at application layer + S3 SSE-KMS at storage layer; per-tenant S3 prefix namespacing; per-tenant KMS key namespacing; DEK-per-tenant envelope encryption via CMK pool.

Observability (Production Target)

Enterprise deployments require structured observability. FastPort's production target includes:

• Structured JSON logging with tenant_id, request_id, user identity, and latency on every request
• Per-tenant metrics dashboards: order volume, check status distribution, webhook delivery rate, error rate by CRA
• Alerting thresholds for: API error rate >1%, P95 latency >500ms, webhook failure rate >5%, CRA callback delay >30m
• Incident runbook with PagerDuty-compatible alerting integration (provisioned at deployment)

Multi-CRA Routing — Failover & Degradation

This section answers the question every enterprise CTO asks: "What happens when one of your upstream systems goes down?"

CRA Circuit Breaker Behavior

SLA Per CRA — Current DISA Integration

How CRA Routing Works — Technical Detail

// Employer submits composable order
POST /v2/orders
{
  "checks": [
    { "type": "criminal_national" },       // → routes to DISA Screen
    { "type": "drug_test",                 // → routes to D360 via DISA
      "config": { "panel": "5-panel", "collection_method": "urine" }
    },
    { "type": "mvr" },                     // → routes to DISA Screen
    { "type": "employment_verification" }  // → routes to Equifax TWN / DISA Screen
  ],
  "consortium_lookup": true,               // → reads DISA Works (non-blocking)
  "issue_fpn_on_clear": true
}

// FastPort CRA Routing Engine resolves:
// 1. Looks up client routing config (tenant_id → routing_rules table)
// 2. Maps each check type to fulfillment CRA
// 3. Submits sub-orders to each CRA concurrently
// 4. Aggregates status as callbacks arrive
// 5. Fires unified webhook to employer on completion

// Result aggregation:
GET /v2/orders/{id}/report
→ Single JSON object, all checks, all CRAs
→ Employer sees one view regardless of which CRA fulfilled each check

CRA Onboarding — How a New CRA Connects

Adding a new CRA to the FastPort network is a back-end configuration change. No client-side changes required.

1. API contract definition — FastPort and the CRA agree on REST endpoint schema and webhook payload format. FastPort provides a CRA partner spec (OpenAPI 3.0).
2. Tenant provisioning — CRA assigned a FastPort partner API key and tenant ID. Per-tenant DEK provisioned; CMK pool assigns tenant namespace. S3 prefix scoped.
3. Check type mapping — Each check type mapped to CRA fulfillment partner(s). Routing rules configurable per client and per check type.
4. Webhook registration — CRA registers outbound webhook endpoint with FastPort. All payloads HMAC-SHA256 signed.
5. Sandbox testing — Full end-to-end test before production cutover. FastPort provides test fixtures for every check type.
6. Production activation — CRA activated; existing orders route transparently per configuration.

Security Model

FCRA Boundary — Architecturally Enforced

The FastPort /fpn/{id}/verify endpoint is architecturally isolated from consumer report data. The verify endpoint has no access to SSN, DOB, or detailed report records. It returns pass/fail + timestamp + issuing CRA only. This boundary is enforced at the database layer via RLS, not solely at the application layer.

Penetration Testing & Security Review

SLA Tiers, Disaster Recovery & Data Residency

SLA Tiers

Disaster Recovery

Data Residency

All data resides in the United States. No cross-border data transfer. All processing is US-based. Data residency can be contractually guaranteed.

Compliance Posture

API Reference — Core Endpoints

All endpoints are relative to https://api.fastportconnect.com/v2. All requests require authentication. All POST endpoints accept an Idempotency-Key header for safe retry.

Example: Composable Screening Order (IS #2b — Existing ATS Client)

POST /v2/orders HTTP/1.1
Host: api.fastportconnect.com
X-FastPort-Key: fp_live_sk_AbCdEf1234567890
X-Idempotency-Key: wkdy-order-2026-0630-00142
Content-Type: application/json

{
  "candidate_id": "cand_9f8e7d6c",
  "package": "custom",
  "checks": [
    { "type": "criminal_national" },
    { "type": "criminal_county" },
    { "type": "drug_test",
      "config": { "panel": "5-panel", "collection_method": "urine" }
    },
    { "type": "employment_verification" },
    { "type": "i9_everify" }
  ],
  "consortium_lookup": true,
  "webhook_url": "https://api.acmecorp.com/fp-callbacks",
  "issue_fpn_on_clear": true
}

// 202 Accepted — async processing begins
// Results delivered via HMAC-signed webhook when complete
// GET /v2/orders/{id}/report for consolidated view at any time

Check Types — Available & Routing

Deployment Model

Current Deployment (Pilot)

Production Scale Target

Integration Scopes — DISA Specific

IS #1 — Unified Client Experience (DCC / DISA Works)

What it delivers: Single login, unified dashboard for DCC consortium clients. Contractor badging via phone — worker presents QR code, supervisor scans, instant FPN verification returns pass/fail.

Technical path: FastPort UI → FastPort API → DISA Works API → unified employer + consortium view → FPN issued on credential completion.

Current state: FPN issuance and QR verify built and tested. Dashboard in pilot. DISA Works API integration: awaiting DISA access credentials.

IS #2a — New Client Onboarding via FastPort

What it delivers: New employer clients onboard directly to FastPort Connect. All DISA capabilities — background, drug, consortium, I-9, WOTC — available from day one in one interface, regardless of which ATS they run.

Technical path: New client → FastPort API → parallel routing to DISA Screen, D360, DISA Works per check type → unified result.

Current state: Routing engine built. Each DISA system integration pending API credential provisioning from DISA. Full end-to-end demo available in sandbox with mock DISA responses.

IS #2b — Existing Client Transparent Proxy (Zero Migration)

What it delivers: Existing ATS integrations point at FastPort's API endpoint. FastPort translates to DISA's internal API formats. Zero migration required on the employer side.

Integration surfaces: ATS integrations via HR-XML/SOAP background check request envelopes and REST + OAuth 2.0 callback flows. Connector pattern is ATS-agnostic — the same orchestration layer accepts any ATS that DISA already supports, with vendor-specific request/response shaping handled in a thin adapter. Final adapter prioritization confirmed against DISA’s integration catalog in onboarding.

// BEFORE: Existing employer integration
ATS → DISA Screen API → background check only
D360 data: manual process, separate system
Consortium: DISA Works, separate login

// AFTER: Same ATS call, new endpoint
ATS → FastPort API (drop-in replacement)
         ↙                ↓              ↘
   DISA Screen       DISA Works         D360
   (background)    (consortium)     (drug test)
         ↘                ↓              ↙
         Unified response — one webhook to ATS
         Background ✓ · Drug test ✓ · Consortium ✓

Current state: Translation layer built and specced. Requires live DISA integration to validate full path. Sandbox demo with mock DISA responses available now. Full production validation in integration sprint.

IS #2.5 — Identity Verification + WOTC at Scale (Stretch Goal)

Architecturally supported now. Requires no structural rebuild. FPN as recurring subscription credential: workers carry verified credential across employers, employers pay for network access. WOTC in pilot (4 additional categories vs. standard coverage). Full-scale rollout post IS #1 + IS #2 validation.

Integration Sequence — Path to Production

1. Partnership agreement signed — commercial terms locked, integration commitment confirmed
2. DISA provisions API credentials — FastPort receives API keys for DISA Screen, DISA Works, D360
3. Integration sprint (est. 4–6 weeks) — FastPort connects live systems in staging, runs full end-to-end test suite
4. Sandbox validation with DISA tech team — Joint testing of all IS #1 + IS #2 flows
5. Pilot client cutover — First DCC client migrated to FastPort unified view
6. Production activation — Monitoring in place, SLA reporting begins, incident runbook live

DISA Platform Integration Points

Sandbox Demo Environment

A working prototype demo is available for technical review. The demo environment runs against seeded sandbox data with mock DISA system integrations (as disclosed in the dependency status at /health). All API endpoints are functional and return realistic DCC-flavored data.