Skip to main content

What This Article Covers

This guide explains how different FrankieOne components relate to each other:
  • Checks — Individual verification tasks
  • Workflows — Collections of checks that run together
  • OneSDK Flow IDs — User interface flows for data collection
  • Entity Profiles (V1 Legacy) — How checks were grouped in the older system
Who should read this:
  • Developers integrating FrankieOne
  • Product managers planning implementations
  • Anyone trying to understand how FrankieOne components fit together

Table of Contents


The Big Picture

Think of FrankieOne verification like building a house:

In Simple Terms

ComponentDescription
OneSDK FlowThe user interface that collects information
EntityThe person or business being verified
WorkflowThe verification process (contains multiple checks)
ChecksIndividual verification tasks (KYC, IDV, AML, etc.)
ResultThe final outcome (PASS, FAIL, REVIEW)

What is a Check?

Definition

A check is a single verification task that validates one aspect of an entity’s identity or compliance status. Think of a check as asking one specific question:
  • “Does this person’s name and address match government records?” (KYC Check)
  • “Is this document authentic?” (IDV Check)
  • “Is this person on any sanctions lists?” (AML Check)

Types of Checks

Check TypeWhat It DoesExample
KYC (Know Your Customer)Verifies identity details against data sourcesChecks name, DOB, address against credit bureau
IDV (Identity Verification)Validates documents and biometricsChecks if passport is authentic, selfie matches photo
AML (Anti-Money Laundering)Screens against watchlistsChecks for PEP, sanctions, adverse media
FraudDetects fraud signalsChecks device, email, phone for fraud indicators
DuplicateFinds duplicate entitiesChecks if person already exists in your system
MatchlistChecks against custom listsChecks against your internal blocklist

Check Lifecycle

Check Created


Check Running ──────┐
     │              │
     ▼              │ (Waiting for data source)
Check Completed ◄───┘

     ├─ PASS
     ├─ FAIL
     ├─ NO_MATCH
     ├─ HIT (for AML)
     └─ ERROR

Example: KYC Check

{
  "checkType": "KYC",
  "checkName": "two_",
  "result": "PASS",
  "details": {
    "nameVerified": true,
    "addressVerified": true,
    "dobVerified": true,
    "matchedSources": [
      "Credit Bureau",
      "Electoral Roll"
    ]
  }
}
What happened:
  • The check verified the person’s name against 2 data sources ✓
  • The check verified the person’s address against 2 data sources ✓
  • Result: PASS

What is a Workflow?

Definition

A workflow is a collection of checks that run together in a specific order to verify an entity. It’s like a recipe that defines:
  • Which checks to run
  • In what order
  • What conditions trigger each check
  • What the final outcome should be

Workflow Structure

Workflow Configuration

Workflows are configured by FrankieOne based on your requirements. Each workflow has: 1. Name Example: Standard-KYC-AU, Enhanced-KYC-US, Basic-KYB-UK 2. Service Profile The category it belongs to (e.g., “KYC”, “KYB”, “Fraud”) 3. Lifecycle Phase
  • ONBOARDING — Initial verification when customer signs up
  • MONITORING — Ongoing checks after onboarding
  • REFRESH — Periodic re-verification
4. Steps The checks to run and their configuration 5. Rules
  • Logic for when to run each check
  • Conditions for PASS/FAIL/REVIEW

Example: API Call to Execute Workflow

// Execute a workflow on an entity
POST /v2/individuals/{entityId}/serviceprofiles/KYC/workflows/Standard-KYC-AU/execute

// Response
{
  "requestId": "req-123",
  "workflowResult": {
    "workflowName": "Standard-KYC-AU",
    "workflowExecutionId": "exec-456",
    "status": "PASS",
    "steps": {
      "passed": ["START", "MATCHLIST", "KYC", "IDV", "AML", "DECISION", "FINISH"],
      "failed": [],
      "incomplete": []
    }
  }
}

What is a OneSDK Flow ID?

Definition

A OneSDK Flow ID is a pre-configured user interface flow that guides users through data collection. It’s the “front-end” experience that collects the information needed for verification. Important: OneSDK Flow IDs are separate from workflows. The flow collects data, then a workflow verifies that data.

Available Flow IDs

Flow IDPurposeWhat It CollectsWhen to Use
idvComplete IDV flowDocument photos + selfie + biometricsFull identity verification with document and face
idv_reviewIDV with user reviewDocument photos + selfie + allows user to edit OCR dataWhen you want users to review/correct extracted data
ocr_onlyDocument OCR onlyDocument photos only (no biometrics)When you only need document data extraction
manual_kyceKYC form onlyUser manually enters personal detailsWhen you don’t need document capture
doc_uploadDocument attachmentDocument files (for business entities)For KYB or supporting documents
individual_doc_uploadDocument attachmentDocument files (for individuals)For additional documents after initial verification

How OneSDK Flows Work

User's Browser/App

       │ 1. Request onboarding URL


Your Backend

       │ 2. Call FrankieOne API
       │    POST /idv/v2/hosted-onboarding-url
       │    Body: { flowId: "idv", entityId: "..." }


FrankieOne API

       │ 3. Returns URL
       │    { url: "https://hosted.frankieone.com/..." }


Your Backend

       │ 4. Send URL to user


User's Browser/App

       │ 5. User opens URL
       │    - Sees document capture screen
       │    - Takes photo of ID
       │    - Takes selfie
       │    - Reviews data


OneSDK (Hosted by FrankieOne)

       │ 6. Data collected
       │    - Document images
       │    - Biometric data
       │    - User consent


FrankieOne Platform

       │ 7. Webhook sent to your backend
       │    "IDV data captured"


Your Backend

       │ 8. Execute workflow
       │    POST /v2/individuals/{entityId}/.../workflows/{workflowName}/execute


FrankieOne Platform

       │ 9. Workflow runs (KYC, IDV, AML checks)


Your Backend

       │ 10. Webhook sent
       │     "Workflow complete - PASS"

Example: Using OneSDK Flow

// Step 1: Generate hosted OneSDK URL
const response = await fetch('https://api.frankie.one/idv/v2/hosted-onboarding-url', {
  method: 'POST',
  headers: {
    'api_key': YOUR_API_KEY,
    'X-Frankie-CustomerID': YOUR_CUSTOMER_ID,
    'Content-Type': 'application/json'
  },
  body: JSON.stringify({
    flowId: 'idv',  // ← This is the Flow ID
    entityId: 'entity-123',
    consent: true,
    sendSMS: true,
    phoneNumber: '+61412999999'
  })
});

const { url } = await response.json();

// Step 2: Send URL to user (via SMS, email, or display in app)
// User completes the flow at this URL

// Step 3: Receive webhook when user completes flow
// Step 4: Execute workflow to verify the collected data

How They Work Together

The Complete Flow

Let’s walk through a real example: verifying a new customer in Australia. Scenario You’re onboarding a new customer named Sarah. You need to:
  • Collect her ID document and selfie
  • Verify her identity details
  • Screen her against watchlists

Step-by-Step Process

1. Create Entity
// Your backend creates an entity
POST /v2/individuals
{
  "name": { "givenName": "Sarah", "familyName": "Smith" },
  "dateOfBirth": { "year": "1990", "month": "05", "day": "15" }
}

// Response
{
  "entityId": "entity-abc-123"
}
2. Generate OneSDK URL with Flow ID
// Your backend requests hosted OneSDK URL
POST /idv/v2/hosted-onboarding-url
{
  "flowId": "idv",  // ← Flow ID: Complete IDV flow
  "entityId": "entity-abc-123",
  "consent": true
}

// Response
{
  "url": "https://hosted.frankieone.com/onboarding/xyz789"
}
3. User Completes OneSDK Flow Sarah opens the URL in her browser:
Screen 1: Welcome & Consent

Screen 2: Select ID Type (Driver License)

Screen 3: Capture Front of License

Screen 4: Capture Back of License

Screen 5: Review Extracted Data

Screen 6: Take Selfie

Screen 7: Liveness Check

Screen 8: Complete
4. OneSDK Sends Data to FrankieOne
Data collected:
- Document images (front & back)
- Extracted data (name, DOB, license number)
- Selfie image
- Biometric data
- User consent
5. Your Backend Receives Webhook
// Webhook from FrankieOne
POST https://your-domain.com/webhook/req-123
{
  "function": "RESULTS_RETRIEVED",
  "entityId": "entity-abc-123",
  "message": "IDV results retrieved"
}
6. Your Backend Executes Workflow
// Now execute the workflow to verify the data
POST /v2/individuals/entity-abc-123/serviceprofiles/KYC/workflows/Standard-KYC-AU/execute

// This workflow contains these checks:
// 1. MATCHLIST - Check internal blocklist
// 2. KYC - Verify name, DOB, address
// 3. IDV - Verify document authenticity & face match
// 4. AML - Screen watchlists
// 5. DECISION - Calculate final result
7. Workflow Runs All Checks
Check 1: MATCHLIST
  Result: CLEAR (not on blocklist)

Check 2: KYC
  Result: MATCH (name & DOB verified)

Check 3: IDV
  Result: PASS (document authentic, face matches)

Check 4: AML
  Result: CLEAR (no watchlist hits)

Check 5: DECISION
  Result: PASS (all checks passed)
8. Your Backend Receives Final Webhook
// Webhook from FrankieOne
POST https://your-domain.com/webhook/req-456
{
  "function": "WorkflowComplete",
  "entityId": "entity-abc-123",
  "workflowExecutionId": "exec-789",
  "overallStatus": "PASS"
}
9. Your Backend Fetches Complete Results
// Fetch full results
GET /v2/individuals/entity-abc-123/serviceprofiles/KYC/workflows/Standard-KYC-AU/executions/exec-789

// Response
{
  "workflowResult": {
    "status": "PASS",
    "riskAssessment": { "riskLevel": "LOW" },
    "steps": {
      "passed": ["MATCHLIST", "KYC", "IDV", "AML", "DECISION"],
      "failed": []
    },
    "workflowStepResults": [
      {
        "stepName": "KYC",
        "result": "MATCH",
        "summary": { /* detailed KYC results */ }
      },
      {
        "stepName": "IDV",
        "result": "PASS",
        "summary": { /* detailed IDV results */ }
      },
      {
        "stepName": "AML",
        "result": "CLEAR",
        "summary": { /* detailed AML results */ }
      }
    ]
  }
}
10. Your System Makes Decision
// Your backend processes the result
if (workflowResult.status === "PASS") {
  // Approve Sarah's account
  await approveCustomer("entity-abc-123");
  await sendEmail(sarah.email, "Account approved!");
}

Visual Summary


V1 vs V2: Entity Profiles vs Workflows

Understanding the Difference

FrankieOne has two API versions with different terminology:
ConceptV1 API (Legacy)V2 API (Current)
Collection of checksEntity Profile / RecipeWorkflow
How to triggerAssign profile to entityExecute workflow on entity
Result objectentityProfileResultworkflowResult
Status fieldactionRecommendedstatus

V1: Entity Profiles (Legacy)

In V1, you assign an “entity profile” (also called a “recipe”) to an entity:
// V1 API
POST /compliance/v1.2/entity/check
{
  "entityId": "entity-123",
  "checkProfile": "KYC_PROFILE_AU"  // ← Entity Profile
}

// Response
{
  "entityProfileResult": {
    "actionRecommended": "PASS",  // ← V1 status field
    "checkResults": [
      { "checkType": "kyc", "result": "PASS" },
      { "checkType": "idv", "result": "PASS" },
      { "checkType": "aml", "result": "CLEAR" }
    ]
  }
}
Key Points:
  • Entity profiles are assigned to entities
  • Checks run automatically when profile is assigned
  • Results in entityProfileResult object
  • Status in actionRecommended field

V2: Workflows (Current)

In V2, you execute a workflow on an entity:
// V2 API
POST /v2/individuals/entity-123/serviceprofiles/KYC/workflows/Standard-KYC-AU/execute

// Response
{
  "workflowResult": {
    "status": "PASS",  // ← V2 status field
    "workflowStepResults": [
      { "stepName": "KYC", "result": "MATCH" },
      { "stepName": "IDV", "result": "PASS" },
      { "stepName": "AML", "result": "CLEAR" }
    ]
  }
}
Key Points:
  • Workflows are executed on entities
  • More explicit control over when checks run
  • Results in workflowResult object
  • Status in status field
  • More detailed step-by-step results

OneSDK Works with Both

Important: OneSDK Flow IDs work with both V1 and V2 APIs. The flow collects data, then you choose whether to use V1 entity profiles or V2 workflows to verify that data.
OneSDK Flow (idv)

       │ Collects data


   Entity Data

       ├─────────────────┬─────────────────┐
       │                 │                 │
       ▼                 ▼                 ▼
   V1 API            V2 API           Direct API
   (Entity Profile)  (Workflow)       (Manual checks)

Common Scenarios

Scenario 1: Simple KYC with Document Verification

Goal: Verify a customer’s identity with document and selfie. Components:
  • OneSDK Flow ID: idv
  • Workflow: Standard-KYC-AU
  • Checks: KYC, IDV, AML
Implementation:
// 1. Create entity
const entity = await createEntity({ name, dob, address });

// 2. Generate OneSDK URL
const { url } = await generateOnboardingURL({
  flowId: 'idv',  // ← Document + selfie capture
  entityId: entity.entityId
});

// 3. Send URL to user
await sendSMS(user.phone, `Complete verification: ${url}`);

// 4. Wait for webhook (user completed flow)
// 5. Execute workflow
const result = await executeWorkflow({
  entityId: entity.entityId,
  workflowName: 'Standard-KYC-AU'  // ← Runs KYC, IDV, AML checks
});

// 6. Process result
if (result.status === 'PASS') {
  await approveCustomer(entity.entityId);
}

Scenario 2: eKYC Only (No Documents)

Goal: Verify customer using only data sources, no document capture. Components:
  • OneSDK Flow ID: manual_kyc
  • Workflow: eKYC-Only-AU
  • Checks: KYC, AML (no IDV)
Implementation:
// 1. Create entity
const entity = await createEntity({ name, dob, address });

// 2. Generate OneSDK URL
const { url } = await generateOnboardingURL({
  flowId: 'manual_kyc',  // ← Form only, no document capture
  entityId: entity.entityId
});

// 3. User fills form
// 4. Execute workflow (no IDV check)
const result = await executeWorkflow({
  entityId: entity.entityId,
  workflowName: 'eKYC-Only-AU'  // ← Runs KYC, AML only
});

Scenario 3: Document OCR Only

Goal: Extract data from document without biometric verification. Components:
  • OneSDK Flow ID: ocr_only
  • Workflow: None (just data extraction)
  • Checks: None initially
Implementation:
// 1. Create entity
const entity = await createEntity({ name });

// 2. Generate OneSDK URL
const { url } = await generateOnboardingURL({
  flowId: 'ocr_only',  // ← Document capture only, no selfie
  entityId: entity.entityId
});

// 3. User captures document
// 4. Receive webhook with OCR data
// 5. Review extracted data
// 6. Optionally execute workflow later

Scenario 4: Re-verification

Goal: Re-verify an existing customer with updated documents. Components:
  • OneSDK Flow ID: idv_review
  • Workflow: Refresh-KYC-AU
  • Checks: IDV, AML (skip KYC if data unchanged)
Implementation:
// 1. Entity already exists
const entityId = 'existing-entity-123';

// 2. Generate OneSDK URL for re-verification
const { url } = await generateOnboardingURL({
  flowId: 'idv_review',  // ← Allows user to review/edit data
  entityId: entityId
});

// 3. User updates document
// 4. Execute refresh workflow
const result = await executeWorkflow({
  entityId: entityId,
  workflowName: 'Refresh-KYC-AU'  // ← Re-runs relevant checks
});

Scenario 5: Business Verification (KYB)

Goal: Verify a business entity with company documents. Components:
  • OneSDK Flow ID: doc_upload
  • Workflow: Standard-KYB-AU
  • Checks: Company registry, AML, UBO verification
Implementation:
// 1. Create organization entity
const org = await createOrganization({
  name: 'Acme Corp',
  registrationNumber: '123456789'
});

// 2. Generate OneSDK URL for document upload
const { url } = await generateOnboardingURL({
  flowId: 'doc_upload',  // ← Business document upload
  entityId: org.entityId
});

// 3. User uploads company documents
// 4. Execute KYB workflow
const result = await executeWorkflow({
  entityId: org.entityId,
  workflowName: 'Standard-KYB-AU'  // ← Runs KYB checks
});

FAQs

Q: Do I need to use OneSDK to use workflows?

A: No. OneSDK is optional. You can:
  • Use OneSDK to collect data (easier, pre-built UI)
  • Build your own UI and send data via API
  • Use a combination (OneSDK for documents, your UI for forms)

Q: Can I use multiple workflows on the same entity?

A: Yes. You can execute different workflows at different times:
  • Initial onboarding: Standard-KYC-AU
  • Ongoing monitoring: Monitoring-AML-AU
  • Re-verification: Refresh-KYC-AU

Q: What’s the difference between a workflow and a check?

A: A workflow contains multiple checks.
  • Check = Single verification task (e.g., “verify document”)
  • Workflow = Collection of checks in a specific order (e.g., “KYC → IDV → AML”)

Q: Can I customize workflows?

A: Yes, but workflows are configured by FrankieOne. Contact your FrankieOne representative to:
  • Create custom workflows
  • Modify existing workflows
  • Add/remove checks
  • Change check order or conditions

Q: What happens if a check fails in a workflow?

A: It depends on the workflow configuration. Common behaviors:
  • Critical check fails → Workflow stops, returns FAIL
  • Non-critical check fails → Workflow continues, returns REVIEW
  • Optional check fails → Workflow continues, may still PASS

Q: Can I run individual checks without a workflow?

A: In V1, yes. In V2, checks are always part of workflows.
  • V1: You can run individual checks via API
  • V2: Checks are organized into workflows (recommended approach)

Q: How do I know which OneSDK Flow ID to use?

A: Choose based on what data you need:
NeedFlow ID
Document + biometricsidv
Document onlyocr_only
Form data onlymanual_kyc
User to review OCR dataidv_review
Upload documentsdoc_upload or individual_doc_upload

Q: Can I use the same workflow for different countries?

A: Usually no. Workflows are typically country-specific because:
  • Different data sources per country
  • Different regulatory requirements
  • Different document types
You’ll typically have:
  • Standard-KYC-AU (Australia)
  • Standard-KYC-US (United States)
  • Standard-KYC-UK (United Kingdom)

Q: What’s the relationship between OneSDK Flow ID and workflow?

A: They’re independent but complementary:
OneSDK Flow ID (Frontend)

Collects Data

Workflow (Backend)

Verifies Data
  • Flow ID = How you collect data from the user
  • Workflow = How you verify that data
You can use any Flow ID with any workflow, as long as the workflow has the data it needs.

Q: Can I change the workflow after it’s started?

A: No, but you can execute a different workflow. Once a workflow execution starts, it runs to completion. If you need different checks, execute a new workflow.

Q: How do I test workflows?

A: Use the UAT environment:
  • FrankieOne provides UAT credentials
  • Execute workflows in UAT
  • Use test data (FrankieOne provides test entities)
  • Review results in UAT Portal
  • Once satisfied, move to production

Q: What if I need a check that’s not in my workflow?

A: Contact FrankieOne to add it. Your FrankieOne representative can:
  • Add checks to existing workflows
  • Create new workflows with different checks
  • Configure check parameters

Summary

Key Takeaways

Check = Single verification task
  • Example: KYC check, IDV check, AML check
Workflow = Collection of checks that run together
  • Example: Standard-KYC-AU workflow contains KYC + IDV + AML checks
OneSDK Flow ID = User interface for data collection
  • Example: idv flow shows document capture + selfie screens
They work together:
  • OneSDK Flow → Collects Data → Workflow → Runs Checks → Result
V1 vs V2:
  • V1: Entity Profiles (legacy)
  • V2: Workflows (current, recommended)

Next Steps

  • Identify your use case: What data do you need to collect? What checks do you need to run?
  • Choose your components: Select appropriate OneSDK Flow ID and identify required workflow
  • Contact FrankieOne: Discuss your requirements, get workflows configured, receive UAT credentials
  • Implement: Integrate OneSDK (if using), integrate API for workflow execution, test in UAT, deploy to production

Need Help?

Contact your FrankieOne representative if you:
  • Need help choosing the right workflow
  • Want to customize workflows
  • Need to add new checks
  • Have questions about OneSDK Flow IDs
  • Need implementation support
Resources: