OpenGrade

Platform

1. Overview

OpenGrade is a financial scoring platform that leverages Israeli Open Finance APIs to generate trust scores from real banking data. Instead of document-based KYC, OpenGrade analyzes transaction patterns, account balances, and spending behavior to produce reliable financial trust indicators.

Key Terms

Client The person or organization requesting a financial check (the platform's paying client)

Applicant The person being checked (authenticates with their bank, receives a copy of their score)

The Problem

Traditional financial verification relies on document-heavy KYC processes. These are slow, invasive, and create privacy risks through PII storage.

The Discovery

Israeli Open Finance APIs (based on NextGenPSD2) provide rich financial behavioral data — transactions, balances, card spending with merchant categories, savings, loans — but return zero personal identifying information.

The Pivot

OpenGrade transforms this behavioral financial data into trust scores. Clients get a reliable financial signal without either party handling sensitive documents or storing PII.

Foundation

2. Research

Our platform is built on the Israeli Open Finance standard, regulated by the Bank of Israel and based on the Berlin Group's NextGenPSD2 XS2A Framework.

Israeli Open Finance Standard

• Based on Berlin Group NextGenPSD2 XS2A Framework
• Regulated by the Bank of Israel Banking Supervision Department
• Phased rollout: current accounts → debit cards → credit, savings, loans → securities
• Third parties registered as AIS (Account Information Service) providers
• Client consent required for each data access via bank OAuth

Available Data

Data Basket	Account List	Details	Balances	Transactions
Current Account	✓	✓	✓	✓
Debit Cards	✓	✓	✓	✓
Savings & Loans	✓	✓	✓	✓
Securities	✓	✓	✓	✓

Key Data Fields Available

transactionAmount transactionDate merchantCategoryCode cardAcceptorAddress transactionDetails balanceAmount balanceType creditLimitIncluded proprietaryBankTransactionCode IBAN currencyExchange bookingDate

Data NOT Available via Open Finance APIs

The APIs return zero personal identifying information. Not available: account holder name, ID number (Teudat Zehut), phone number, date of birth, address, or any other PII.

This limitation is what drove the pivot from identity verification to behavioral financial scoring.

Related Work & Market Context

• Credit Kudos (UK) — Open Banking credit scoring acquired by Apple, 2022
• ClearScore (UK) — Free credit scores using Open Banking data
• Plaid / Finicity (US) — Financial data aggregation platforms
• BDI / CreditGuard (Israel) — Traditional credit data providers

OpenGrade differs by focusing on behavioral scoring from Open Finance data in the Israeli market, with a zero-PII-storage architecture.

Strategy

3. Business Model

Primary

Financial Trust Checks

Verify any individual's financial stability before making a decision. Send a check link, get a score — no documents needed.

Client creates a financial check request
Sends OpenGrade check link to the applicant
Applicant authenticates with their bank
Client receives financial trust score

Feature

Scheduled Rescoring

Clients can schedule recurring or one-time rescores of existing applicants. The platform uses recurring bank consent to fetch fresh data automatically — no applicant interaction needed while consent is active.

Client sets a rescore schedule (e.g., monthly)
Platform uses stored recurring consent token
Fresh bank data fetched automatically (~2-3 sec)
Updated score delivered to dashboard

Use Case Breadth

Rental Screening

Verify a prospective renter's financial stability before signing a lease

Freelancer Vetting

Companies assess financial reliability of contractors before project engagement

Peer Lending

Individuals evaluate financial trustworthiness before lending money or sharing expenses

Loan Pre-Qualification

Lenders get a quick financial health signal before formal application processing

Insurance Underwriting

Insurers assess an applicant's financial behavior to inform risk pricing and policy decisions

Vehicle & Equipment Leasing

Leasing companies evaluate financial reliability before approving vehicle or equipment contracts

Registration Integration

Embed financial checks directly into company signup flows via API for seamless onboarding

Token-Based Pricing

Clients purchase token packs upfront. Checks consume tokens based on the number of data baskets accessed — pay only for the data you need.

Per-Basket Pricing

1 token per data basket accessed (1–4 tokens depending on check scope)

Rescore

Same rate as baskets refreshed — automated via recurring consent

Token Packs

Buy in bulk at a discount — tokens never expire

Volume Discounts

10–30% off for high-volume integrations (100+ tokens)

Volume Discount Tiers

Tier	Tokens Purchased	Discount
Standard	1–99	Base price
Growth	100–499	10% off
Scale	500–1,999	20% off
Enterprise	2,000+	30% off

Baskets Accessed	Scope	Cost
1 — Current Account only	Basic balance + income check	1 token
2 — + Debit Cards	+ spending patterns	2 tokens
3 — + Savings & Loans	+ savings & debt profile	3 tokens
4 — + Securities	Comprehensive financial check	4 tokens

End-to-End Flow

1

Client Registration

Client creates an account on the platform

2

Create Check

Client enters applicant's email address and a label (e.g., 'Q2 Contractor Check')

3

Email Invitation

System sends a verification link to the applicant's email

4

Applicant Verification

Applicant verifies email via OTP, accepts legal attestation, authenticates with bank via Open Finance OAuth

5

Score Computation

Platform fetches financial data, computes score in-memory, discards raw data immediately

6

Score Delivery (Client)

Client sees traffic-light score (green/yellow/red) with top contributing factors on dashboard

7

Score Delivery (Applicant)

Applicant receives a copy of their score via email

Scenarios

4. Use Cases

UC-1: Financial Check Primary

Actors

Client, Applicant

Precondition

Client has a registered OpenGrade account

Main Flow

Client creates a new check, entering applicant's email and a label
System generates unique check link and sends it to applicant's email
Applicant opens the link and verifies their email address via OTP
Applicant reads and accepts the legal attestation
Applicant authenticates with their bank via Open Finance OAuth
System fetches financial data and computes score in-memory
Score (traffic-light + factors) is displayed to client and emailed to applicant

Alternative Flows

• Verification expires: System sends verification email with 48-hour expiry. Reminder sent at 24 hours. After 48 hours: check status → EXPIRED, client notified via dashboard and email. No tokens consumed. Client can resend the check.
• Applicant declines auth: Applicant reaches bank auth screen but declines or closes the window. Check status → DECLINED, client notified. No tokens consumed. Client can resend with a new verification link.
• Partial bank data: Some banks don't support all 4 data baskets. Score computed with available baskets at lower confidence (MEDIUM or LOW). Tokens charged only for baskets actually fetched. Factor labels indicate which factors could not be assessed.
• Bank connection error: OpenFinance.ai returns ERROR status (bank downtime or provider issue). System retries automatically up to 3 times over 15 minutes. If all retries fail: check status → EXPIRED. No tokens consumed. Client can resend.

Postcondition

Score and consent records stored. Raw financial data discarded.

UC-2: Scheduled Rescoring

Actors

Client, Existing Applicant

Precondition

Applicant has a previous score with active recurring bank consent

Main Flow

Client sets a rescore schedule when creating a check (or later via dashboard)
System stores rescore_cron on the bank connection record
Scheduler triggers at the configured time, verifies connection is ACTIVE
System triggers data refresh via OpenFinance.ai, fetches fresh bank data
New check record created with updated score, raw data discarded
Updated score delivered to client dashboard and emailed to applicant

Alternative Flows

• Consent expired: Scheduler detects connection status EXPIRED. Rescore skipped, client notified. System sends re-consent email to applicant with new bank auth link. If applicant doesn't respond within 48 hours, rescore schedule paused until re-authentication.
• Consent revoked: Applicant revoked consent via their bank's app. Connection status → REVOKED. Rescore permanently stopped, client notified. Client must create a new check to re-engage the applicant.
• Insufficient tokens: Scheduler checks client token balance before rescoring. If insufficient, rescore skipped and client emailed. Schedule preserved — rescore resumes automatically once balance is topped up.

Performance

Rescores with active consent complete in ~2-3 seconds (API calls only, no user interaction).

UC-3: Client Registration & Dashboard

Actors

Client

Client registers on the platform, verifies their email, and gains access to the dashboard. From the dashboard, the client can view check history, see score results, create new checks, and manage rescore schedules.

Client registers with email and password
Client verifies email address
Client accesses dashboard
Client views check history and score results
Client creates new checks

UC-4: Score Dispute & Data Deletion

Actors

Applicant

Applicant contacts the platform to request a score review or data deletion. The platform deletes check records containing the applicant's email upon request.

Applicant contacts platform via support channel
Applicant requests score review or data deletion
Platform verifies applicant identity via email
Platform deletes check records containing applicant's email

GDPR Article 17 — Right to Erasure

UC-5: Consent Management

Actors

Applicant

Applicant grants bank-level consent during the check flow. Consent can be one-time or recurring (per NextGenPSD2 recurringIndicator). Recurring consent enables automated rescoring without applicant interaction.

Applicant grants bank-level consent during check flow
If client has scheduled rescoring, recurring consent requested via refreshData: true on the OpenFinance.ai connection
Connection stored with expiryDate (up to 90 days per PSD2). System tracks connection status.
Connection expires → status updated to EXPIRED, re-consent link sent automatically to applicant
Applicant can revoke consent at any time via their bank

UC-6: Error Recovery & Notifications

Actors

System, Client, Applicant

The platform handles failures gracefully across the check lifecycle. Every error produces a notification to the relevant party and, where possible, an automated recovery action.

Error	Affected	System Action	Recovery
Verification expired	Client + Applicant	Check → EXPIRED, no tokens charged	Client resends check
Applicant declines	Client	Check → DECLINED, no tokens charged	Client resends check
Bank connection error	Client	Retry 3×, then → EXPIRED	Client resends check
Partial bank data	Client + Applicant	Score with lower confidence, fewer tokens	None needed
Consent expired	Client + Applicant	Rescore paused, re-consent email sent	Applicant re-authenticates
Consent revoked	Client	Rescore stopped permanently	New check required
Insufficient tokens	Client	Action blocked, email notification	Client purchases tokens
Provider suspended	Client	Check paused, client notified	Wait for restoration

No tokens are ever charged until bank data is successfully fetched. Failed checks before the bank data stage cost the client nothing.

UC-7: Embedded Registration Integration API

Actors

Client (Company), Applicant (End User)

Precondition

Client has configured webhook URL, callback URL, and integration settings

Companies embed an OpenGrade financial check as a step in their user registration flow. Instead of the email-invitation model, the company's backend initiates the check via API and redirects the user through attestation + bank auth. The score is delivered asynchronously via webhook.

Main Flow

Company's backend calls POST /api/checks/embedded with applicant email and callback URL
OpenGrade returns a unique check_url and check_id
Company redirects the user to the check_url
User reads and accepts the legal attestation (OTP skipped — company already verified identity)
User authenticates with their bank via Open Finance OAuth
User is immediately redirected back to the company's callback URL with status=pending
OpenGrade computes the score asynchronously and fires a webhook to the company's backend
Company receives the score and continues their registration flow

Alternative Flows

• Webhook delivery fails: System retries with exponential backoff (10s, 30s, 1m, 5m, 30m, 1h — 6 attempts). Company can poll GET /api/checks/:id as fallback.
• User abandons bank auth: Check status → DECLINED. Webhook fires with check.declined. No tokens charged.
• Check URL expires (72h): Check status → EXPIRED. Webhook fires with check.expired. No tokens charged.
• Insufficient tokens: POST /api/checks/embedded returns 402. Company must purchase more tokens.

Score Detail Levels

Level	Fields Returned
Basic	score, traffic_light
Standard	score, traffic_light
Detailed	score, traffic_light, factors, confidence

Postcondition

Score delivered via webhook. Raw financial data discarded. Webhook signed with HMAC-SHA256.

Rescoring

Optional add-on — companies can enable recurring rescoring per check after initial completion.

System Design

5. Architecture

System Architecture

graph TD CP["🖥️ Client Portal
Dashboard"] --> GW["🔒 API Gateway
Auth · Rate Limit · Routing"] SP["📱 Applicant Page
Bank Verification"] --> GW SCH["⏰ Scheduler
Recurring Rescores"] --> CO GW --> CO["📋 Check Orchestrator
Check Lifecycle"] GW --> CM["👤 Client Management
Registration · Auth"] CO --> BI["🏦 Bank Integration
Open Finance OAuth"] BI --> SE["📊 Scoring Engine
Stateless Compute"] CO --> SE SE --> SS[("💾 Score Storage
Results · Consents")] CO --> AL[("📝 Audit Logger
Immutable Events")] BI -.->|"Open Finance API"| BANK["🏛️ Israeli Banks"] style CP fill:#0c1520,stroke:#1e3a5f,stroke-width:1.5px,color:#d4d4d8 style SP fill:#0c1520,stroke:#1e3a5f,stroke-width:1.5px,color:#d4d4d8 style SCH fill:#1a1508,stroke:#4a3f18,stroke-width:1.5px,color:#d4d4d8 style GW fill:#18181b,stroke:#3f3f46,stroke-width:1.5px,color:#d4d4d8 style CO fill:#18181b,stroke:#3f3f46,stroke-width:1.5px,color:#d4d4d8 style CM fill:#18181b,stroke:#3f3f46,stroke-width:1.5px,color:#d4d4d8 style BI fill:#0a1a15,stroke:#1a4a35,stroke-width:1.5px,color:#d4d4d8 style SE fill:#1a1508,stroke:#4a3f18,stroke-width:1.5px,color:#d4d4d8 style SS fill:#13101c,stroke:#3a2e5c,stroke-width:1.5px,color:#d4d4d8 style AL fill:#13101c,stroke:#3a2e5c,stroke-width:1.5px,color:#d4d4d8 style BANK fill:#0a1a15,stroke:#1a4a35,stroke-width:1.5px,color:#d4d4d8

API Gateway

Express.js middleware layer handling JWT authentication, rate limiting (per-client, per-endpoint via Redis), CORS enforcement, and request routing. Not a separate service — wraps all routes.

Client Management

Client registration, authentication, and token balance management.

Method	Endpoint	Description
POST	/api/clients/register	Register new client account
POST	/api/clients/login	Authenticate, receive JWT
GET	/api/clients/me	Get profile + token balance
POST	/api/clients/tokens/purchase	Purchase token pack
PUT	/api/clients/integration	Configure embedded integration (webhook URL, callback, score detail level)

Check Orchestrator

Manages the full check lifecycle: create request, send applicant verification link, wait for bank auth, trigger scoring, and deliver results.

Method	Endpoint	Description
POST	/api/checks	Create a new check (deducts tokens)
GET	/api/checks	List client's checks (filterable)
GET	/api/checks/:id	Get check details + score
POST	/api/checks/:id/rescore	Trigger manual rescore
GET	/api/checks/:id/report	Download score report
POST	/api/checks/embedded	Create embedded check (registration integration)

Bank Integration

Internal module called by Check Orchestrator. Handles OpenFinance.ai connection creation, PSD2 bank auth initiation, and data fetching. Does not persist any financial data.

Method	Endpoint	Description
GET	/verify/:token	Applicant landing page (bank auth flow)
POST	/api/webhooks/openfinance	Connection status callback

Scoring Engine

Stateless computation. Receives normalized financial data, applies the 7-factor weighted model, and returns a score with contributing factors. No side effects, no storage.

Scheduler

Manages recurring rescore jobs. Scans connections with active rescore schedules, verifies connection is ACTIVE, triggers data refresh via OpenFinance.ai, and creates new check records with updated scores. Monitors consent expiry and notifies clients.

Audit Logger

Immutable append-only event log recording all system events: CHECK_CREATED, BANK_AUTH_INITIATED, BANK_AUTH_COMPLETED, SCORE_GENERATED, SCORE_ACCESSED, RESCORE_TRIGGERED, CONNECTION_EXPIRED, TOKENS_PURCHASED.

Data Flow Principle

Bank API → In-Memory Processing → Score Only → Storage

Raw financial data exists only in memory during scoring. Never persisted.

Open Finance API Integration

The platform integrates with OpenFinance.ai — an Israeli Open Finance aggregator providing PSD2-compliant access to bank data.

Endpoint	Method	Purpose
/oauth/token	POST	Obtain API access token (clientId + clientSecret + userId)
/connections	POST	Create connection with refreshData, expiryDate, startDate
/connect/open-banking-init	POST	Initiate PSD2 bank OAuth (providerId + psuId + connectionId)
/data/accounts	GET	Fetch account details and balances
/data/transactions	GET	Fetch transaction history (with MCC codes, amounts, dates)
/connections/refresh/{connectionId}	GET	Trigger fresh data fetch for rescore (ACTIVE connections)
/connections/{connectionId}	GET	Check connection status, expiryDate, lastFetchedDataDate

Connection Statuses

INACTIVE → FETCHING → CONNECTED → ACTIVE | COMPLETED

Terminal: EXPIRED REVOKED ERROR SUSPENDED_BY_PROVIDER

Supported Israeli Banks

Hapoalim Leumi Discount Mizrahi Beinleumi Mercantile Otsar Hahayal Yahav Pagi UBank Pepper

Banks only — card transaction data is accessible through bank connections.

Recurring Consent & Rescoring

OpenFinance.ai supports two connection types via PSD2: one-time (status: COMPLETED after fetch) and recurring (status: ACTIVE — data refreshable on demand). PSD2 consent lasts ~90 days. We set expiryDate at connection creation and use rescore_cron to schedule automated rescores.

First Score

Create connection (POST /connections, refreshData: true) → applicant authenticates via PSD2 OAuth (POST /connect/open-banking-init) → status: ACTIVE → fetch & score.

~30 sec (user-dependent)

Automated Rescore

Scheduler fires on rescore_cron schedule → verifies connection ACTIVE → triggers GET /connections/refresh/{connectionId} → fetches latest data → creates new check record with fresh score. Zero applicant involvement.

~2-3 sec (automated)

Consent Expired

Connection status changes to EXPIRED or REVOKED. System notifies client, sends re-consent link to applicant. New connection created once re-authenticated. Expiry controlled via expiryDate param.

Re-consent required

We store the OpenFinance.ai connectionId and userId only — never raw financial data. The rescore_cron on the connection controls automated rescoring frequency.

Tech Stack

Backend

Node.js 18+ / Express.js

Database

PostgreSQL 15+ / Prisma ORM

Cache

Redis

Auth

JWT RS256 + OAuth 2.0 PKCE

Frontend

React or Angular + Tailwind CSS

Bank Data

OpenFinance.ai PSD2 API

Infrastructure

Docker

Database Schema

4 tables. No applicants table — applicant email lives on check and connection records. No banks table — OpenFinance.ai manages the provider registry. No raw financial data stored anywhere.

clients

Column	Type	Description
id	UUID	Primary key
email	VARCHAR	Client's email (unique, login credential)
password_hash	VARCHAR	bcrypt hash
name	VARCHAR	Display name (shown on check invitations)
token_balance	INTEGER	Available scoring tokens
created_at	TIMESTAMP	Registration timestamp

checks

Column	Type	Description
id	UUID	Primary key
client_id	FK → clients	Requesting client
connection_id	FK → connections	Bank connection used (NULL until authenticated)
applicant_email	VARCHAR	Applicant's email address
label	VARCHAR	Client's label (e.g., “Q2 Contractor Check”)
status	ENUM	PENDING, SENT, BANK_AUTH, SCORING, COMPLETED, EXPIRED, DECLINED
score	INTEGER	Final score (0–100), NULL until computed
factors_json	JSONB	Contributing factor labels and weights
confidence	ENUM	HIGH, MEDIUM, LOW (based on data completeness)
tokens_consumed	INTEGER	Tokens charged (1 per data basket processed)
created_at	TIMESTAMP	Check creation time
completed_at	TIMESTAMP	Score delivery time, NULL until completed

connections

Column	Type	Description
id	UUID	Primary key
client_id	FK → clients	Owning client
applicant_email	VARCHAR	Applicant this consent covers
of_connection_id	VARCHAR	OpenFinance.ai connection ID
of_user_id	VARCHAR	OpenFinance.ai user ID
provider_id	VARCHAR	Bank identifier (e.g., “hapoalim”)
status	ENUM	ACTIVE, COMPLETED, EXPIRED, REVOKED, ERROR
rescore_cron	VARCHAR	Cron expression for automated rescores (NULL = manual only)
expiry_date	DATE	PSD2 consent expiration
last_fetched_at	TIMESTAMP	Last successful data fetch
created_at	TIMESTAMP	Connection creation time

Stores IDs and status only — never raw financial data.

audit_logs

Column	Type	Description
id	UUID	Primary key
event_type	VARCHAR	CHECK_CREATED, BANK_AUTH, SCORE_GENERATED, SCORE_ACCESSED, etc.
check_id	FK → checks	Related check (nullable for non-check events)
client_id	FK → clients	Related client
metadata_json	JSONB	Event-specific metadata
created_at	TIMESTAMP	Event timestamp (immutable, append-only)

Algorithm

6. Scoring Engine

Rule-based scoring with weighted factors. Fully explainable — each factor has a clear, labeled contribution to the final score. No machine learning (no training data available for initial version).

Score Range

0–100

0–39 Red · 40–69 Yellow · 70–100 Green

Factor Labels

Top 3–5 contributing factors with clear labels (e.g., "Stable monthly income", "Low credit utilization")

Confidence

High (4+ data baskets), Medium (2–3), Low (1)

Financial Scoring Model

Factor	Weight	Data Source	Calculation
Income stability	25%	Current account transactions	Recurring deposits (salary) — consistency of timing and amount over 3–6 months
Balance health	20%	Current account balances	Average balance, minimum balance, frequency of near-zero/negative balances
Expense discipline	15%	Card transactions + MCC codes	Essential spending ratio (groceries, utilities, transport) vs. discretionary
Recurring payment consistency	15%	Current account transactions	Recurring fixed outgoing payments — timeliness and consistency
Savings behavior	10%	Savings account data	Existence of savings, growth trend, balance level
Credit utilization	10%	Card balances + credit limits	Percentage of available credit used (lower is better)
Risk flags	5%	Card transactions MCC codes	Gambling MCC codes, payday loan indicators, high-risk patterns

Example Score Breakdown

81/100 — Green

Confidence: High

Contributing Factors

Income Stability

22/25 (Strong)

Balance Health

16/20 (Good)

Expense Discipline

11/15 (Moderate)

Recurring Payments

12/15 (Good)

Savings Behavior

8/10 (Good)

Credit Utilization

7/10 (Good)

Risk Flags

5/5 (No flags)

Score Calibration & Weight Optimization

Before production deployment, the scoring algorithm undergoes a structured calibration process to validate that factor calculations and weight distributions produce meaningful, fair, and discriminating scores.

Phase 1 — Synthetic Dataset Generation

Generate 500+ synthetic financial profiles spanning the full spectrum of applicant archetypes:

Green Profiles (70–100)

Stable salary, healthy balances, low credit utilization, consistent recurring payments, active savings

Yellow Profiles (40–69)

Irregular income, occasional low balances, moderate credit usage, some late payments, minimal savings

Red Profiles (0–39)

No stable income, frequent overdrafts, maxed credit, missed payments, gambling MCC flags

Each profile includes 3–6 months of mock transactions, balances, card data, and savings — matching real OpenFinance.ai API response schemas.

Phase 2 — Individual Factor Validation

Each of the 7 scoring factors is tested in isolation to verify its sub-score calculation behaves correctly:

Test	Method	Pass Criteria
Boundary values	Feed minimum, maximum, and edge-case inputs for each factor	Sub-score stays within 0–weight range, no NaN/infinity
Monotonicity	Gradually improve input quality (e.g., increase income regularity)	Sub-score increases monotonically — better data = higher score
Missing data	Omit data basket (e.g., no savings account)	Factor gracefully defaults, confidence level decreases
Known-answer	Hand-calculated expected scores for specific profiles	Engine output matches hand calculation within ±1 point

Phase 3 — Weight Sensitivity Analysis

Run the full synthetic dataset through the engine while systematically varying weights to understand their impact:

1.

Baseline run — score all 500+ profiles with default weights (25/20/15/15/10/10/5). Record score distribution.

2.

Single-factor perturbation — for each factor, shift its weight by ±5% (redistributing to other factors proportionally). Measure how the Green/Yellow/Red distribution shifts.

3.

Distribution targets — adjust weights until the synthetic dataset produces approximately 30% Green, 45% Yellow, 25% Red — reflecting expected real-world distribution.

4.

Discrimination power — verify that clearly-good profiles always score Green and clearly-bad profiles always score Red. Yellow zone should contain genuinely ambiguous profiles.

Outputs: sensitivity matrix showing how each ±5% weight shift affects final score distribution, plus optimized weight set.

Phase 4 — Fairness & Bias Review

Ensure the scoring model does not inadvertently penalize specific demographic patterns:

•

Income pattern diversity — freelancers/gig workers with irregular but sufficient income should not be auto-penalized vs. salaried workers

•

Single vs. multi-bank — applicants with one bank account should not score lower than those with multiple accounts

•

Spending category fairness — MCC-based expense categorization should not penalize cultural spending patterns

•

Data basket availability — verify the confidence score properly signals limited data rather than producing falsely low scores

Phase 5 — Rescore Stability Testing

Simulate the recurring rescoring pipeline to validate score consistency over time:

•

Stable applicant — same financial behavior across refreshes should produce scores within ±3 points (noise tolerance)

•

Improving applicant — gradually improving finances should show a clear upward trend in scores

•

Deteriorating applicant — worsening finances should trigger score decline and eventual zone change (Green → Yellow → Red)

•

Data gap — if a refresh returns fewer data baskets than initial fetch, score should adjust confidence rather than drop dramatically

Compliance

7. Security & Privacy

In Transit

TLS 1.3 for all communications

At Rest

AES-256-GCM encryption for score results and audit logs

In Memory

Raw financial data zeroed after scoring computation

Authentication & Tokens

•

Client Auth: JWT with RS256 + refresh tokens for dashboard sessions

•

Applicant Auth: Delegated to bank via PSD2 OAuth (Strong Customer Authentication). Platform never sees bank credentials.

•

OpenFinance.ai API Token: Short-lived access token obtained via POST /oauth/token (clientId + clientSecret + userId). Auto-renewable, no user interaction. expiresIn returned in milliseconds.

•

Bank Connection (Consent): PSD2 connection object with configurable expiryDate. Stays ACTIVE for recurring access until expired or revoked by applicant.

Two-Token Architecture

API Access Token

Platform ↔ OpenFinance.ai

Short-lived, auto-renewable

+

Bank Connection

Applicant's bank consent

Long-lived, user-revocable

=

Data Access

Both required to fetch

bank data for scoring

Anti-Fraud Measures

•

Email verification (OTP) — applicant must verify email before bank auth

•

Legal attestation — applicant confirms "I am the account holder"

Known limitation: Since the API returns no PII, the platform cannot programmatically verify that the person authenticating is the intended applicant. Email verification + attestation serve as deterrents.

Privacy by Design

No PII Storage

Beyond client accounts and applicant emails on check records

No Financial Data Storage

Raw transactions, balances, card details are never persisted

Consent-Scoped Access

Each check requires explicit bank-level consent

Purpose Limitation

Data fetched for a check is used only for that check

Right to Erasure

Delete check records containing the applicant's email on request

Auto-Expiry

Check records expire after configurable retention period

Regulatory Positioning

By storing only scores (not financial data), the platform positions as an information service rather than a financial data processor, significantly reducing regulatory surface area.

POC Scope

8. Proof of Concept

Objective

Demonstrate the end-to-end flow of bank-data-driven financial scoring, from client check creation through applicant bank authentication to score delivery, using a mock bank API.

In-Scope

✓ Client registration and login (dashboard)

✓ Check creation flow (enter applicant email + label)

✓ Applicant verification flow (email OTP → attestation → bank OAuth)

✓ Scoring pipeline (fetch mock bank data → compute score in-memory → store result)

✓ Score delivery (client dashboard + email to applicant)

✓ Financial scoring model (7 factor categories)

✓ Mock bank API (simulates Open Finance API responses)

✓ Scheduled rescoring with recurring consent (mock consent tokens)

✓ Token balance management (purchase, consume, track)

Out-of-Scope

✗ Payment/billing integration (real payment processing)

✗ Multi-bank authentication

✗ Advanced anti-fraud

✗ Score history analytics and trend graphs

✗ Mobile-native app

✗ Real bank sandbox integration

Success Criteria

☐ Client can register, create a check, and receive a score

☐ Applicant can verify email, authenticate with mock bank, and receive a score

☐ Score is computed from Open Finance API fields (mock data)

☐ Raw financial data is demonstrably not stored after scoring

☐ Full flow completes in under 30 seconds

Team & Work Plan

Team

Amit Zamir Noa Elmakies May Gurevich Hai Tal

Milestones

1

Foundation

Project setup, CI/CD, database schema, mock bank API

2

Core Flow

Check orchestration, bank integration, basic scoring

3

Scoring Engine

Full scoring model implementation, confidence scoring

4

Client Experience

Dashboard, score visualization, email delivery

5

Polish & Demo

Testing, documentation, presentation preparation

Product Preview

9. Demo

Product Walkthrough

Explore all 9 screens of the OpenGrade flow — from check creation through bank authentication to score delivery.

View Demo

9 screens · 2 perspectives · 1 seamless flow

Slides

10. Presentation

Sources

11. References

Regulatory & Standards

Bank of Israel — Open Banking Standards and Guidelines
Berlin Group — NextGenPSD2 XS2A Framework
Open Finance Forum Fintech-Architects Presentation (March 2022) — Bank of Israel
OpenFinance.ai — API Documentation (docs.open-finance.ai)
Israeli Privacy Protection Law (חוק הגנת הפרטיות)
EU General Data Protection Regulation (GDPR)

Technologies

Node.js — Server-side JavaScript runtime

Express.js — Minimal web framework

PostgreSQL — Relational database

Prisma — Next-generation ORM

Redis — In-memory data store

Docker — Container platform

OAuth 2.0 — Authorization framework

JWT / JWS — Token-based authentication

OpenID Connect — Identity layer on OAuth 2.0

Tailwind CSS — Utility-first CSS framework

Mermaid.js — Diagram rendering

NextGenPSD2 — Open banking API standard

OpenFinance.ai — Israeli bank data aggregator

Bank Data Scoring

Zero PII Storage

Token-Based Pricing

1. Overview

The Problem

The Discovery

The Pivot

2. Research

Israeli Open Finance Standard

Available Data

Key Data Fields Available

Data NOT Available via Open Finance APIs

Related Work & Market Context

3. Business Model

Financial Trust Checks

Scheduled Rescoring

Use Case Breadth

Token-Based Pricing

End-to-End Flow

4. Use Cases

UC-1: Financial Check Primary

UC-2: Scheduled Rescoring

UC-3: Client Registration & Dashboard

UC-4: Score Dispute & Data Deletion

UC-5: Consent Management

UC-6: Error Recovery & Notifications

UC-7: Embedded Registration Integration API

5. Architecture

System Architecture

Data Flow Principle

Open Finance API Integration

Recurring Consent & Rescoring

Tech Stack

Database Schema

6. Scoring Engine

Financial Scoring Model

Example Score Breakdown

Score Calibration & Weight Optimization

7. Security & Privacy

Authentication & Tokens

Anti-Fraud Measures

Privacy by Design

Regulatory Positioning

8. Proof of Concept

Objective

In-Scope

Out-of-Scope

Success Criteria

Team & Work Plan

9. Demo

Product Walkthrough

10. Presentation

11. References

Regulatory & Standards

Technologies