Understanding Checks, Workflows, and OneSDK Flows in FrankieOne

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

The Big Picture
What is a Check?
What is a Workflow?
What is a OneSDK Flow ID?
How They Work Together
V1 vs V2: Entity Profiles vs Workflows
Common Scenarios
FAQs

The Big Picture

Think of FrankieOne verification like building a house:

In Simple Terms

Component	Description
OneSDK Flow	The user interface that collects information
Entity	The person or business being verified
Workflow	The verification process (contains multiple checks)
Checks	Individual verification tasks (KYC, IDV, AML, etc.)
Result	The 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 Type	What It Does	Example
KYC (Know Your Customer)	Verifies identity details against data sources	Checks name, DOB, address against credit bureau
IDV (Identity Verification)	Validates documents and biometrics	Checks if passport is authentic, selfie matches photo
AML (Anti-Money Laundering)	Screens against watchlists	Checks for PEP, sanctions, adverse media
Fraud	Detects fraud signals	Checks device, email, phone for fraud indicators
Duplicate	Finds duplicate entities	Checks if person already exists in your system
Matchlist	Checks against custom lists	Checks 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., “DEFAULT”, “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/DEFAULT/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 ID	Purpose	What It Collects	When to Use
`idv`	Complete IDV flow	Document photos + selfie + biometrics	Full identity verification with document and face
`idv_review`	IDV with user review	Document photos + selfie + allows user to edit OCR data	When you want users to review/correct extracted data
`ocr_only`	Document OCR only	Document photos only (no biometrics)	When you only need document data extraction
`manual_kyc`	eKYC form only	User manually enters personal details	When you don’t need document capture
`doc_upload`	Document attachment	Document files (for business entities)	For KYB or supporting documents
`individual_doc_upload`	Document attachment	Document 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/idvalidate/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/idvalidate/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/idvalidate/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/DEFAULT/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/DEFAULT/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:

Concept	V1 API (Legacy)	V2 API (Current)
Collection of checks	Entity Profile / Recipe	Workflow
How to trigger	Assign profile to entity	Execute workflow on entity
Result object	`entityProfileResult`	`workflowResult`
Status field	`actionRecommended`	`status`

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/DEFAULT/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:

Need	Flow ID
Document + biometrics	`idv`
Document only	`ocr_only`
Form data only	`manual_kyc`
User to review OCR data	`idv_review`
Upload documents	`doc_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:

API Documentation: https://docs.frankieone.com
OneSDK Documentation: https://docs.frankieone.com/docs/about-onesdk
Support: Contact your FrankieOne representative

Onboarding Guides

Developers

Documentation Index

​What This Article Covers

​Table of Contents

​The Big Picture

​In Simple Terms

​What is a Check?

​Definition

​Types of Checks

​Check Lifecycle

​Example: KYC Check

​What is a Workflow?

​Definition

​Workflow Structure

​Workflow Configuration

​Example: API Call to Execute Workflow

​What is a OneSDK Flow ID?

​Definition

​Available Flow IDs

​How OneSDK Flows Work

​Example: Using OneSDK Flow

​How They Work Together

​The Complete Flow

​Step-by-Step Process

​Visual Summary

​V1 vs V2: Entity Profiles vs Workflows

​Understanding the Difference

​V1: Entity Profiles (Legacy)

​V2: Workflows (Current)

​OneSDK Works with Both

​Common Scenarios

​Scenario 1: Simple KYC with Document Verification

​Scenario 2: eKYC Only (No Documents)

​Scenario 3: Document OCR Only

​Scenario 4: Re-verification

​Scenario 5: Business Verification (KYB)

​FAQs

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

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

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

​Q: Can I customize workflows?

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

​Q: Can I run individual checks without a workflow?

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

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

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

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

​Q: How do I test workflows?

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

​Summary

​Key Takeaways

​Next Steps

​Need Help?

What This Article Covers

Table of Contents

The Big Picture

In Simple Terms

What is a Check?

Definition

Types of Checks

Check Lifecycle

Example: KYC Check

What is a Workflow?

Definition

Workflow Structure

Workflow Configuration

Example: API Call to Execute Workflow

What is a OneSDK Flow ID?

Definition

Available Flow IDs

How OneSDK Flows Work

Example: Using OneSDK Flow

How They Work Together

The Complete Flow

Step-by-Step Process

Visual Summary

V1 vs V2: Entity Profiles vs Workflows

Understanding the Difference

V1: Entity Profiles (Legacy)

V2: Workflows (Current)

OneSDK Works with Both

Common Scenarios

Scenario 1: Simple KYC with Document Verification

Scenario 2: eKYC Only (No Documents)

Scenario 3: Document OCR Only

Scenario 4: Re-verification

Scenario 5: Business Verification (KYB)

FAQs

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

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

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

Q: Can I customize workflows?

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

Q: Can I run individual checks without a workflow?

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

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

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

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

Q: How do I test workflows?

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

Summary

Key Takeaways

Next Steps

Need Help?