OpenGrade

One bank connection.
Verified identity, scored trust.

A privacy-first layer on Israeli Open Finance: a consented bank login proves a real person — then scores their financial trust. We store nothing.

Real-person verification 0–100 trust score Zero data stored

Amit ZamirBackend & Architecture

Noa ElmakiesProblem & Market

May GurevichProduct & Demo

Hai TalScoring & Validation

Final Project Defense · Fintech & Algorithmic Trading · COLMAN B.Sc. CS Supervisor: Ari Ben Ephraim · Project Day 2026

Presenter · Noa The pain

Trust scoring is broken.

A landlord, lender or business has to bet on a stranger's reliability — armed only with tools that are opaque, leaky, or easy to fake.

Scores don't explain themselves

Traditional credit scores hand back a black-box number. No factors, no recourse, nothing you can question or act on.

Statements spill PII

Bank statements and salary slips expose everything — salary, address, every transaction — to a landlord who only needed one signal.

Self-reported data lies

References and uploaded PDFs are gameable. The applicant curates exactly what you see — the risky signal is the one omitted.

OpenGradeThe Problem

Presenter · Noa Why now

Open Finance changed what's possible.

Israel's Open Finance regime (PSD2-style) lets a person grant read-only, consented access to their real bank data through a regulated API — no documents, no manual collection.

The twist

The API returns transactions, balances and credit behavior — but no identifying information: no name, ID, address or date of birth.

So identity-based verification is impossible by design. The only thing left to score is behavior — which is exactly the signal that actually predicts reliability.

WHAT THE BANK API RETURNS

✓ Transactions (6 mo) ✓ Account balances ✓ Credit utilization ✓ Recurring payments

WHAT IT NEVER RETURNS

✕ Name ✕ National ID ✕ Address ✕ Date of birth

OpenGradeWhy Now

Presenter · Noa Who it's for

One score, four trust decisions.

Renting Primary

Landlords vet a tenant's reliability before handing over the keys.

Lending

P2P & micro-lenders risk-price a borrower on live data, not stale bureau signals.

Hiring

A financial-stability signal for cash-handling or compliance-sensitive roles.

Partnership

Verify a counterparty's financial health before a deal — skip audited statements.

Client — the party requesting the check. Pays per check. (landlord, lender, business)

Applicant — the person being checked. Authenticates with their bank. Pays nothing.

OpenGradeMarket & Use Cases

Presenter · May Our solution

Real bank data → an instant 0–100 trust score, without storing a single document.

Scoring factors,
each labeled & weighted

0PII

No name, ID, or raw
financial data stored

<5min

From "create check"
to score delivered

Use-case profiles,
each with learned weights

Transparent 7-factor scores Privacy-first by design Live & deployed

OpenGradeOur Solution

Presenter · May Beyond the score

Have a bank account? You're a real person.

Every OpenGrade check rides on a bank connection — and that connection is itself proof of a real person. Identity verification is built in: a consented bank login proves a unique, real human. No documents, no selfie — and in this mode we read no financial data at all.

Verify mode

Just connect the bank. We collect and store nothing — the successful, consented connection is the proof.

✓ Verified human0 data read · 0 stored

Score mode

Read → score → forget. Seven factors become a 0–100 trust score, then the raw data is deleted.

85 · Greenread in memory · deleted after scoring

Verify unlocks a far bigger market

MarketplacesDating & socialP2P lendingFintech onboardingBot & fraud defense

OpenGradeIdentity Verification

Presenter: May. Before the demo, the big idea for the investors in the room. Everything we've described reads bank data — but the connection itself carries a signal we almost threw away. If a person can complete a real, consented login to their own bank, they are, by definition, a verified, unique human — banks already did the hard KYC. So identity verification isn't a bolt-on — it's intrinsic to how OpenGrade already works. Every check runs on a bank connection, and that connection alone proves a real, unique human. In Verify mode we simply stop there: read no financial data, store nothing — the successful connection is the whole signal. That's proof-of-personhood without a single document or selfie. Score mode is our deep product for landlords and lenders; the same connection, used lightly, is an identity check that drops into marketplaces, dating, P2P, onboarding, and bot defense — a far larger market, from one integration.

Presenter · May · Demo 1 / 3 Product · the client

Create a check in two fields.

Pick a use case

Renting, lending, hiring… sets which weights apply.

Enter applicant email

Spends one credit. An invitation link is emailed automatically.

Watch it score live

The result lands on the dashboard in real time — no refresh.

OpenGradeDemo · Client Flow

Presenter · May · Demo 2 / 3 Product · the applicant

Consent, then connect the bank.

Verify email (OTP)

Proves the invited person opened it. Rate-limited.

Legal attestation

"I am the account holder." Decline → check canceled, credit refunded.

Bank auth in Open Finance

Bank selection & consent happen inside the regulated provider's iframe.

Score, then forget

We fetch, score in memory, and delete the raw data — instantly.

▶ Play the 15-sec product walkthrough →

OpenGradeDemo · Applicant Flow

Presenter · May · Demo 3 / 3 Product · the result

Not a black box.

TRUST SCORE · RENTING

Green · Good Confidence MEDIUM · single account

Real engine output, pinned in our test suite.
Input: ₪8,000 salary · ₪6,000 balance · ₪5,000 savings · no defaults.

GREEN 70–100 · YELLOW 40–69 · RED 0–39

CONTRIBUTING FACTORS · SHIPPED WITH EVERY SCORE

Income Stability100

Recurring Payments50

Balance Health70

Expense Discipline55

Savings Behavior63

Credit Utilization50

Risk Flags1 minor flagirregular income−2

OpenGradeDemo · The Score

Presenter · Amit How it works

One pipeline, data minimized at every hop.

Client (React 19)

dashboard · SSE

⇄

API · Express + TypeScript

check state machine · scoring pipeline

⇄

Open Finance API

consented bank data

PostgreSQL · Prisma

scores + audit only

Redis

sessions · rate limits

Gmail SMTP

invites · OTP · results

The scoring pipeline fetch (parallel) → deduplicate → score the 7 factors → persist score → delete raw data → push result over SSE. Raw transactions live only in memory and one short-lived table that is deleted in the same transaction that saves the score.

React 19 · ViteExpress 4 · TSPrisma 6 · Postgres 15Redis 7BetterAuthServer-Sent EventsDocker Compose

OpenGradeArchitecture

Presenter · Hai Technical depth · 1

We learned the weights — we didn't guess them.

Hand-tuned weights are just guesswork — "why 25%?" has no real answer. So we built an ML pipeline that derives them per use case.

2,500 synthetic applicants — 500 per use case, seeded & reproducible.

LLM-judge labels — Claude scores each against a use-case rubric.

Non-negative regression — coefficients ≥ 0, normalized to sum to 1.

Bootstrap SEs — 200 resamples quantify weight uncertainty.

Training fit R² = 0.88–0.96 · every score records its weightsVersion

LEARNED WEIGHTS — RENTING PROFILE

Income Stability57.9%

Recurring Pmts19.2%

Balance Health7.0%

Risk Flags6.6%

Expense Disc.6.0%

Savings2.5%

Credit Util.0.7%

Partnership flips this — savings & balance dominate. Same engine, different learned profile.

OpenGradeTechnical Depth · Learned Weights

Presenter: Hai. This is the part the course rewards: depth. Early on we hand-picked the factor weights, and an examiner-style question killed it — "why is income 25 and not 30?" We had no answer. So we replaced intuition with a pipeline. We generate 2,500 synthetic applicants, 500 per use case, fully seeded so it reproduces. We have an LLM judge score each one against a use-case rubric — that gives us labels. Then we fit a non-negative least-squares regression, force the coefficients positive, and normalize them to sum to one. We even bootstrap 200 times to get error bars on each weight. The result, for renting: income stability dominates at 58%, recurring payments next. For partnership, savings and balance dominate instead — same engine, learned profile. And every score we store records exactly which weights version produced it.

Presenter · Amit Technical depth · 2

The hard parts we actually solved.

Zero-PII data lifecycle

Raw bank data lives in one short-lived table, deleted in the same DB transaction that persists the score. Provable, not promised.

Real-time without polling

Server-Sent Events push every status transition — invited → verified → scoring → done — straight to the dashboard.

Concurrency-safe scoring

An atomic guarded updateMany ensures a check scores exactly once, even if participants finish simultaneously.

Resilient bank integration

Async bank auth is polled with back-off; flaky calls retried (5xx/429), fatal ones aren't. Degrades gracefully to lower confidence.

OpenGradeTechnical Challenges

Presenter: Amit. Four engineering problems worth highlighting. First, the zero-PII lifecycle: the raw data deletion and the score insert happen in one transaction — if the score saves, the raw data is already gone. Second, real-time: we used Server-Sent Events, not polling, so status flows push live. Third, a concurrency bug we hit — in a group check, two applicants finishing at the same millisecond could trigger scoring twice. We fixed it with an atomic guarded update so only the first wins. Fourth, the bank API is async and occasionally flaky, so we poll with back-off, retry transient errors but not fatal ones, and if the full report fails we still score on accounts and transactions at reduced confidence. These are the kinds of failures a real integration throws at you, and we handled them.

Presenter · Hai Validation · evidence over claims

Tested against a real benchmark.

We scored the UCI German Credit dataset (1,000 real labeled records) with our learned weights and measured AUC against two baselines.

Use case	AUC	vs. baselines
Partnership	0.728	beats both ✓
Hiring	0.722	beats both ✓
Other	0.703	beats both ✓
Lending	0.655	passes gate, trails prior
Renting	0.581	weak on this dataset

Baselines — uniform weights 0.641 · prior hand-tuned 0.657

What we're honest about

German Credit's features map only loosely onto our 7 factors — and the learned Lending weights clear the 0.65 gate but narrowly trail the prior hand-tuned set (0.655 vs 0.657), so they're not shipped for lending yet.

50+

test files

weight-contract tests

ML pipeline tests

OpenGradeResults & Validation

Presenter: Hai. We didn't want to claim the score works — we wanted to test it. So we took the UCI German Credit dataset, a thousand real labeled credit records, mapped its features onto our seven factors, and measured AUC. Partnership, hiring and other clear both baselines comfortably, in the low-0.7s. And here's where we're deliberately honest: renting scores poorly on this dataset — 0.58 — because German Credit's fields map only loosely onto our renting-specific factors. And the learned lending weights pass our 0.65 gate but trail our old hand-tuned weights by two thousandths, so we have NOT shipped them for lending. We'd rather show examiners a real, mixed result with a working test harness than a marketing number. That honesty is itself the result. The system is also covered by 50-plus test files including contract tests that enforce the weights are valid.

Presenter · Hai Business model

Pay per check. No subscription.

Clients buy credits up front and spend one per check. Bigger packs lower the per-check price — and declined or failed checks are refunded.

Pay-per-use

No subscription · credits never expire

Lean cost

Marginal cost per check ≈ one Open Finance call

Fair

You only pay for a delivered score

CREDIT PACKS

PRICE · PER CHECK

Starter	10 credits	₪40	₪4.00
Standard	25 credits	₪90	₪3.60 · −10%
Pro	50 credits	₪160	₪3.20 · −20%
Enterprise	100 credits	₪280	₪2.80 · −30%

Prices served live from the API · mock checkout for the academic build

OpenGradeBusiness Model

Presenter · Hai Journey & what's next

From characterization to a deployed product.

✓

Characterization

Pivoted to behavior-scoring once we hit the zero-PII constraint.

✓

POC

Full check flow specced & built — client, applicant, scoring, SSE.

✓

ML & validation

Learned weights + German-Credit benchmark + test suite.

✓

Deployed

Running on the college server with live docs & CI.

Verify a human. Score the risk. Store nothing.

Next · payment processor Next · broader validation Next · partner API

Live · opengrade.cs.colman.ac.il/docs

Amit Zamir · Noa Elmakies · May Gurevich · Hai Tal

Questions welcome

OpenGradeSummary & Ask

One bank connection.Verified identity, scored trust.