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

Landlord The person requesting a financial check (the platform's paying customer)

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

The Problem

Traditional tenant 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. Landlords get a reliable financial signal without either party handling sensitive documents or storing PII.

How It Works

1

Create Check

Landlord enters tenant's email and a label for the check

2

Bank Authentication

Tenant verifies email, then authenticates with their bank via Open Finance

3

Score Computation

Financial data is analyzed in-memory. Raw data is never stored

4

Score Delivered

Landlord receives a traffic-light score with top contributing factors

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
• Customer 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

Tenant Scoring for Landlords

Landlords verify prospective tenants' financial stability before signing a lease. Send a check link, get a score — no documents needed.

Landlord posts apartment listing
Sends OpenGrade check link to prospective tenant
Tenant authenticates with their bank
Landlord receives financial trust score

Feature

Scheduled Rescoring

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

Landlord 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

Token-Based Pricing

Landlords purchase token packs upfront. Each scoring check consumes tokens from their balance. No subscriptions, no recurring fees — pay for what you use.

Initial Check

1 token — full scoring with bank authentication

Rescore

1 token — automated via recurring consent, no tenant interaction

Token Packs

Buy in bulk at a discount — tokens never expire

End-to-End Flow

1

Landlord Registration

Landlord creates an account on the platform

2

Create Check

Landlord enters tenant's email address and a label (e.g., 'Tenant for Herzl 5')

3

Email Invitation

System sends a verification link to the tenant's email

4

Tenant Verification

Tenant 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 (Landlord)

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

7

Score Delivery (Tenant)

Tenant receives a copy of their score via email

Scenarios

4. Use Cases

UC-1: Tenant Financial Check Primary

Actors

Landlord, Prospective Tenant

Precondition

Landlord has a registered OpenGrade account

Main Flow

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

Alternative Flows

• Email not verified within 48 hours → check expires
• Tenant declines bank authentication → check marked as declined
• Bank returns partial data → score computed with lower confidence level

Postcondition

Score and consent records stored. Raw financial data discarded.

UC-2: Scheduled Rescoring

Actors

Landlord, Existing Tenant

Precondition

Tenant has a previous score with active recurring bank consent

Main Flow

Landlord sets a rescore schedule on an existing check (one-time or recurring)
Scheduler triggers at the configured time
System uses stored recurring consent token to fetch fresh bank data
New score computed in-memory, raw data discarded
Updated score delivered to landlord dashboard and emailed to tenant

Alternative Flows

• Recurring consent expired → system sends re-consent link to tenant
• Tenant revoked bank consent → rescore fails, landlord notified
• Insufficient tokens → rescore skipped, landlord notified to top up

Performance

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

UC-3: Landlord Registration & Dashboard

Actors

Landlord

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

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

UC-4: Score Dispute & Data Deletion

Actors

Tenant

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

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

GDPR Article 17 — Right to Erasure

UC-5: Consent Management

Actors

Tenant

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

Tenant grants bank-level consent during check flow
If landlord has scheduled rescoring, recurring consent is requested
Consent token stored securely (valid up to 90 days per PSD2)
Consent expires → re-consent link sent automatically
Tenant can revoke consent at any time via their bank

System Design

5. Architecture

System Architecture

graph TD CP["🖥️ Landlord Portal
Dashboard"] --> GW["🔒 API Gateway
Auth · Rate Limit · Routing"] SP["📱 Tenant Page
Bank Verification"] --> GW SCH["⏰ Scheduler
Recurring Rescores"] --> CO GW --> CO["📋 Check Orchestrator
Check Lifecycle"] GW --> CM["👤 Landlord 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

NGINX/Express middleware handling JWT authentication, rate limiting, CORS enforcement, and request routing to internal services.

Check Orchestrator

Manages the full check lifecycle: create request, generate tenant verification link, email delivery, wait for bank auth, trigger scoring, and deliver results.

Bank Integration Service

Interfaces with the OpenFinance.ai API. Authenticates via POST /oauth/token, creates connections via POST /connections with refreshData: true for recurring access, initiates PSD2 bank auth via POST /connect/open-banking-init, and fetches data via GET /data/accounts and GET /data/transactions. Does not persist any financial data.

Scoring Engine

Stateless computation. Receives normalized financial data, applies the tenant scoring model, and outputs a score with contributing factors. No side effects, no storage.

Landlord Management Service

Landlord registration, authentication, token balance management, and rescore scheduling.

Score Storage

PostgreSQL database storing minimal data: score results, consent records, landlord accounts, and check metadata. No raw financial data.

Audit Logger

Immutable append-only event log recording all system events: check requested, bank auth completed, score generated, score accessed.

Scheduler

Manages recurring and one-time rescore jobs. For ACTIVE connections, triggers refresh via GET /connections/refresh/{connectionId} then re-scores. Monitors connection statuses and alerts landlords when consent expires (EXPIRED/REVOKED).

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 Max Cal Isracard Amex

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

No tenants table — tenant email is stored on the check record only. No raw financial data is stored anywhere.

landlords

Column	Type	Description
id	UUID	Primary key
email	VARCHAR	Landlord'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
landlord_id	FK → landlords	Requesting landlord
tenant_email	VARCHAR	Tenant's email address
label	VARCHAR	Landlord's label (e.g., "Herzl 5, Apt 3")
status	ENUM	PENDING, SENT, VERIFIED, SCORING, COMPLETED, EXPIRED, DECLINED
link_token	VARCHAR	Unique verification link token (hashed)
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)
connection_id	FK → connections	Associated bank connection
rescore_schedule	VARCHAR	Cron expression or NULL (no rescoring)
created_at	TIMESTAMP	Check creation time
completed_at	TIMESTAMP	Score delivery time, NULL until completed

connections

Column	Type	Description
id	UUID	Primary key
check_id	FK → checks	Associated check
of_connection_id	VARCHAR	OpenFinance.ai connection ID
of_user_id	VARCHAR	OpenFinance.ai user ID
provider_id	VARCHAR	Bank provider (e.g., "hapoalim", "leumi")
psu_id_hash	VARCHAR	Hashed national ID (never stored in plain text)
status	ENUM	ACTIVE, COMPLETED, EXPIRED, REVOKED, ERROR
refresh_data	BOOLEAN	Recurring (true) vs one-time (false)
expiry_date	DATE	Consent expiration date
last_fetched_at	TIMESTAMP	Last successful data fetch
created_at	TIMESTAMP	Connection creation time
updated_at	TIMESTAMP	Last status change

Maps to OpenFinance.ai connection objects. 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)
landlord_id	FK → landlords	Related landlord
metadata_json	JSONB	Event-specific metadata
created_at	TIMESTAMP	Event timestamp (immutable, append-only)

banks

Column	Type	Description
id	UUID	Primary key
name	VARCHAR	Display name (e.g., "Bank Hapoalim")
provider_id	VARCHAR	OpenFinance.ai provider ID (e.g., "hapoalim")
supported_scopes	JSONB	Available data baskets (accounts, cards, savings, loans, securities)
status	ENUM	ACTIVE, SANDBOX, INACTIVE

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)

Tenant Scoring Model B2C

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
Rent payments	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

Recurring Consent & Rescoring

OpenFinance.ai supports two connection types via PSD2: one-time (status: COMPLETED after fetch) and recurring (status: ACTIVE — platform auto-fetches daily). We use recurring connections with refreshData: true to power automated rescoring.

First Score

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

~30 sec (user-dependent)

Automated Rescore

Connection ACTIVE → trigger GET /connections/refresh/{connectionId} → fetch latest data via /data/accounts & /data/transactions → re-score. Zero tenant involvement.

~2-3 sec (automated)

Consent Expired

Connection status changes to EXPIRED or REVOKED. System notifies landlord, sends re-consent link to tenant. 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 connection object tracks status, lastFetchedDataDate, and expiryDate to manage the rescore lifecycle.

Example Score Breakdown

78/100 — Green

Confidence: High

Contributing Factors

Income Stability

22/25 (Strong)

Balance Health

16/20 (Good)

Expense Discipline

11/15 (Moderate)

Rent Payments

12/15 (Good)

Savings Behavior

8/10 (Good)

Credit Utilization

7/10 (Good)

Risk Flags

2/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 tenant archetypes:

Green Profiles (70–100)

Stable salary, healthy balances, low credit utilization, consistent rent 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 — tenants 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 tenant — same financial behavior across refreshes should produce scores within ±3 points (noise tolerance)

•

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

•

Deteriorating tenant — 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

•

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

•

Tenant 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 tenant.

Two-Token Architecture

API Access Token

Platform ↔ OpenFinance.ai

Short-lived, auto-renewable

+

Bank Connection

Tenant's bank consent

Long-lived, user-revocable

=

Data Access

Both required to fetch

bank data for scoring

Anti-Fraud Measures

•

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

•

Legal attestation — tenant 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 tenant. Email verification + attestation serve as deterrents.

Privacy by Design

No PII Storage

Beyond landlord accounts and tenant 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 tenant'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 landlord check creation through tenant bank authentication to score delivery, using a mock bank API.

In-Scope

✓ Landlord registration and login (dashboard)

✓ Check creation flow (enter tenant email + label)

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

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

✓ Score delivery (landlord dashboard + email to tenant)

✓ Tenant scoring model (B2C, 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

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

☐ Tenant 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

Landlord Experience

Dashboard, score visualization, email delivery

5

Polish & Demo

Testing, documentation, presentation preparation

Product Preview

9. Demo

OpenGrade

Dashboard

My Checks

Tenant for Herzl 5, TA

● 82 2 hours ago

Tenant for Dizengoff 12

● 55 1 day ago

Tenant for Ben Yehuda 3

◷ Pending 3 days ago

Select Your Bank

H

Bank Hapoalim

L

Leumi Bank

D

Discount Bank

M

Mizrahi Tefahot

L

בנק לאומי

אישור גישה למידע פיננסי

OpenGrade מבקשת גישה לנתונים הבאים:

יתרות חשבון עו״ש תנועות בחשבון עסקאות כרטיסי אשראי חסכונות והלוואות

Score Result

82

Green — Financially Stable

High Confidence

Tenant for Herzl 5, Tel Aviv

Contributing Factors:

● Stable monthly income — Strong
● Consistent rent payments — Strong
● Healthy savings balance — Good
● Moderate credit utilization — Good
● No risk flags detected — Good

Your Score Result

82

Green — Financially Stable

This score was generated on Feb 24, 2026

Requested by: Landlord (Herzl 5, Tel Aviv)

Contributing Factors:

● Stable monthly income — Strong
● Consistent rent payments — Strong
● Healthy savings balance — Good
● Moderate credit utilization — Good
● No risk flags detected — Good

Questions? Contact support@opengrade.io

Sources

10. 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

Related Products & 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
OpenFinance.ai — Israeli Open Finance integration platform

OpenGrade focuses on behavioral scoring from Open Finance data in the Israeli market with a zero-PII-storage architecture — a unique positioning in this space.

Bank Data Scoring

Zero PII Storage

Token-Based Pricing

1. Overview

The Problem

The Discovery

The Pivot

How It Works

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

Tenant Scoring for Landlords

Scheduled Rescoring

Token-Based Pricing

End-to-End Flow

4. Use Cases

UC-1: Tenant Financial Check Primary

UC-2: Scheduled Rescoring

UC-3: Landlord Registration & Dashboard

UC-4: Score Dispute & Data Deletion

UC-5: Consent Management

5. Architecture

System Architecture

Data Flow Principle

Open Finance API Integration

Tech Stack

Database Schema

6. Scoring Engine

Tenant Scoring Model B2C

Recurring Consent & Rescoring

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

My Checks

Create New Check

Verify Your Email

Select Your Bank

אישור גישה למידע פיננסי

Score Result

10. References

Regulatory & Standards

Technologies

Related Products & Market Context