SCROLL
PASSID Credentials  ·  PASSID Verify  ·  Institution-controlled decisioning Signed claims  ·  Scoped tokens  ·  Audit metadata Credential infrastructure only PASSID Credentials  ·  PASSID Verify  ·  Institution-controlled decisioning Signed claims  ·  Scoped tokens  ·  Audit metadata Credential infrastructure only
For banks, lenders & fintech platforms
Currently in pilot

The credential layer for financial trust.

PASSID turns user-permissioned financial history into portable, cryptographically signed credentials institutions can verify in one API call - without receiving raw financial data or giving up control of the final decision.

Verifier workflow
InstitutionsWho verifies
Scoped claimsCredential tokens
No raw feedsVerifier payload
Your policyFinal decision

PASSID verifies claims. Institutions decide.

Verifier response
200 OK
income_verifiedTRUE
identity_verifiedTRUE
sanctions_clearTRUE
credential_freshness48h
raw_bank_feedNOT SENT
final_decisionINSTITUTION
verify.json JSON
POSTapi.passid.io/api/v1/bridge/verify
"token""psid_sandbox_demo_001" }
200 OK sandbox
"credential_valid"true"environment""sandbox",
"signature_valid"true"token_status""active",
"claims.income_verified"true"raw_transactions_included"false,
"decisioning.provided_by_passid"false
Audit trail
Institution key Idempotency Webhook Timestamped Exportable
Swipe to reveal

Credential infrastructure — controlled pilot

Controlled pilot Sandbox verification available Signed claim verification No raw transaction data to verifiers Institution-owned decisioning
Built for institutional review
Banks
Fintech platforms
Credit unions
Rental platforms
Student finance teams
Cross-border onboarding teams

Pilot programme open. Contact hello@passid.io to discuss your use case.

How PASSID works

Four steps from user consent to institution verification.

Users connect financial sources, PASSID creates signed credential claims, users share scoped tokens, and institutions verify the claims inside their own systems.

PASSID Credential Infrastructure
connect account → issue credential → verify credential
STEP 01
🏦
User connects financial sources
The user connects supported financial sources with consent. PASSID reads the signals needed to create claims.
Flow 01
STEP 02
🔐
PASSID creates signed claims
PASSID normalizes user-permissioned signals into a signed, portable credential with freshness and revocation metadata.
Flow 02
STEP 03
🧠
User shares a scoped token
The applicant chooses what to share and hands the institution a scoped PASSID token.
Consent
STEP 04
Institution verifies and decides
The institution verifies signed claims, freshness, revocation, and audit metadata without receiving raw financial data feeds.
Flow 03
Banks → Credentials
Signals → PASSID Credential
PASSID → Verification
What PASSID is
Signed financial credential infrastructure.
A verifier API for consented claims.
User-controlled financial proof.
What PASSID is not
Not a public scoring product.
Not a credit bureau.
Not a bank.
Not a institution decision workflow.
Not a raw transaction feed for verifiers.
Try the verify flow

Submit a PASSID token. Inspect signed claims.

Use a sandbox token to see the institution-facing response shape. Demo data is synthetic and for integration testing only.

No raw financial statements in the verifier response
Institution decision is not provided by PASSID

PASSID does not approve, deny, price, lend, or underwrite. Institutions own all final decisions.

POST /api/v1/bridge/verify
X-Institution-Key: <institution_key>

{ "token": "psid_demo_student_001" }

{
"token_status": "active",
"credential_subject": "user_demo_001",
"claims": {
"identity_verified": true,
"income_verified": true,
"savings_consistency": "stable",
"payment_reliability": "strong",
"sanctions_clear": true,
"fraud_risk": "low"
},
"freshness": { "generated_at": "2026-04-30T10:00:00Z", "valid_until": "2026-05-02T10:00:00Z" },
"revocation": { "revoked": false },
"institution_decision": "not_provided_by_passid"
}
Why institutions use PASSID

Verify financial trust without unnecessary raw data exposure.

PASSID helps banks, fintechs, lenders, insurers, landlords, and platforms accept signed, revocable, auditable credential claims while keeping onboarding, risk, and compliance decisions inside their own systems.

01
Reduce manual statement and document review
02
Improve onboarding for newcomers, students, migrants, gig workers, and thin-file users
03
Use signed claims with freshness, revocation, and audit metadata
04
Keep decisioning, policy, and compliance ownership in-house
What PASSID is / is not

Credential infrastructure. Not a lender or bureau.

PASSID is
Credential infrastructure
Token-based verification
Signed claims
User-permissioned
Institution-controlled decisioning
PASSID is not
A credit bureau
A lender
A bank
A public scoring product or bureau file
A replacement for institution-controlled decisioning
A raw transaction feed
The Problem

Financial identity doesn't travel.

When people cross a border, their credit history often stays behind. Disciplined financial behavior becomes hard for local institutions to verify quickly and fairly.


PASSID changes the primitive. Instead of relying only on a bureau file, institutions can verify signed financial behavior claims with user consent.


No credit bureau dependency required
Designed for cross-border credential verification
No raw transaction feed in the verifier response
Fairness and governance review included in pilot validation
📋
History resets at the border
Three years of responsible banking in Lagos means nothing in London. Moving resets the clock to zero.
💸
Non-traditional income ignored
Gig economy, remittance, and seasonal work are often penalized when models cannot categorize them cleanly.
🔒
Privacy vs access trade-off
No one should hand over raw financial statements to prove creditworthiness. There is a better way.
Manual verification is slow
Repeated document checks add days and cost. Portable credential verification removes that friction.
Solutions

Solutions for people building trust across borders - and institutions that need a better way to verify it.

Choose a solution path to see exactly how PASSID works for that audience, why it matters, and where they enter the product.

Dedicated pages User and institution paths Clear next steps
Target corridors for pilot validation

Priority corridors for pilot planning and integration.

These corridors represent priority pilot markets and integration targets. They are examples of where PASSID's credential architecture is designed to apply — not all corridors are live in production. Contact us to discuss your specific corridor requirements.

🇬🇧🇺🇸
UK → US
Pilot target
🇮🇳🇺🇸
IN → US
Pilot target
🇰🇪🇺🇸
KE → US
Pilot target
🇳🇬🇬🇧
NG → UK
Pilot target
🇸🇳🇺🇸
SN → US
Pilot target
🇲🇽🇺🇸
MX → US
Pilot target
🇵🇭🇺🇸
PH → US
Pilot target
🇧🇩🇬🇧
BD → UK
Pilot target
🇵🇰🇺🇸
PK → US
Pilot target
🇬🇭🇺🇸
GH → US
Pilot target

These corridors represent priority pilot markets and integration targets. Not all corridors are live in production. Institutions test using sandbox credentials before any live rollout.

Technology

Built like infrastructure.
Not like a dashboard.

PASSID is built for open-banking style financial data connections and transforms verified financial signals into portable, verifiable credentials.

Every architectural decision serves verifier trust: signed claims, freshness, revocation, and auditability.

01
Proof Metadata
Credential responses include proof type, issuer signature status, freshness, provenance, and revocation metadata for verifier policy checks.
02
Freshness + Revocation
Credential expiry and revocation endpoints let institutions check whether a presented credential is still usable at verification time.
03
AML + Sanctions Screening
Verification workflows can include OFAC, EU, and UN list checks, PEP identification, and audit records for institution review.
04
Governance Review Support
Pilot partners can review claim performance, exception rates, revocation behaviour, and corridor-level outcomes using institution-defined governance criteria during the pilot review process.
05
Minimal Verifier Payloads
Verifiers receive scoped claim summaries and verification metadata rather than financial statements or transaction feeds.
🏢
Signal Sources
PSD2 · Account aggregators · Mobile money
INPUT
Encrypted data ingestion
⚙️
passid-core
5-pillar signal model · AML · Bias check
COMPUTE
Credential proof package
🔒
passid-issuer
Issuer signature · Proof metadata · Revocation
ISSUE
Signed portable credential
📡
passid-verifier
REST API · claim verification · audit-ready
VERIFY
Signed claims + audit metadata
🏛️
Institution System
Policy workflow · No raw feed stored
DECIDE
Pilot validation

Evidence institutions review before rollout.

PASSID is built for controlled pilots where institutions can test credential verification, review claim accuracy, and validate integration before production use.

📊
Claim accuracy validationHow accurately credential claims reflect underlying financial signals, tested against synthetic and real pilot data.
Completion rate by segmentVerification completion across user segments — students, migrants, gig workers, thin-file applicants.
📋
Manual review reductionReduction in manual document review where credential claims replace statement checks during pilot testing.
🔒
Data minimisation reviewConfirmation that no raw transaction data reaches institution systems — only scoped claim summaries and audit metadata.
Why PASSID

Not a bureau bridge. A behavior protocol.

Existing solutions often port a bureau file, connect raw data, or verify a single income source. PASSID packages user-permissioned financial history into reusable, cryptographically signed credentials. Institutions verify scoped claims, then apply their own policy.

Bureau portability
Moving a foreign credit file
Requires an existing credit bureau file in the origin country
Gig, informal, and non-traditional income not captured
Institution receives a translated bureau report or raw-data workflow
Requires bilateral bureau partnership per corridor
Limited to corridors where partner bureaus exist
PASSID
Verifying real financial behavior
Works from day one using user-permissioned financial signals, not only bureau history
Cashflow, savings, gig income, and remittance all become verified signals
Institution receives structured credential claims without raw financial data exposure
Single API integration — no bureau partnerships required
Extends across corridors as supported financial signal sources become available
👤
Works from zero history
A migrant arriving on day one with no local credit file can present verified financial signals from supported origin-country sources as a signed credential.
💸
Behavior, not history
PASSID reads cashflow, savings discipline, income regularity, and spending patterns — not a repayment record that only exists if someone was previously banked in the right country.
🔒
No raw data to lenders
Institutions receive verified claim summaries and freshness metadata. No financial statements, no transaction lists, no raw PII — making compliance review significantly simpler.
One verifier API for controlled pilots
No bilateral bureau agreements. No corridor-specific bureau integrations. One API call supports credential verification for each corridor configured during pilot onboarding.
For Developers

Verify a PASSID token with one API call.

The verifier API returns token status, signed credential claims, freshness, revocation, and audit metadata. PASSID verifies the credential package; your institution applies its own policy.

1
Create sandbox key
Use an institution key server-side. Demo tokens return synthetic sandbox claims for integration testing.
2
POST /api/v1/bridge/verify
Submit the scoped PASSID token from the user and include X-Institution-Key in the request header.
3
Apply institution policy
Map verified claims into your onboarding, compliance, or risk workflow. PASSID does not approve, deny, or underwrite.
PythonNode.jsRubyJavaGoREST APIWebhooks
verify.http
POST /api/v1/bridge/verify
X-Institution-Key: <institution_key>

{ "token": "psid_sandbox_demo_001" }

200 OK  sandbox
{
"credential_valid": true, "environment": "sandbox",
"token_status": "active", "signature_valid": true,
"claims": {
"identity_verified": true, "income_verified": true,
"income_band": "3000_4000_monthly",
"savings_consistency": "stable", "sanctions_clear": true
},
"freshness": { "data_window_days": 180, "valid_until": "2026-05-30T14:12:00Z" },
"revocation": { "revoked": false },
"audit": { "audit_id": "vrf_sandbox_82a4c9", "raw_transactions_included": false },
"decisioning": { "provided_by_passid": false }
}
Compliance & Security

Built for regulated financial institutions.

Every design decision serves the same goal: making credential verification easier for compliance, risk, and engineering teams to review.

🛡️
AML & Sanctions
Screening outputs can be included in credential verification workflows for institution review.
OFAC SDN list
EU Consolidated list
UN Security Council list
PEP identification
🔒
Privacy by Design
Verifier payloads are designed around scoped claims rather than raw statements.
No raw financial statements in verifier response
Claim-level consent
GDPR-aligned architecture
Right to revoke credential
⚖️
Governance Review
Pilot partners can review claim performance and outcome distribution using their own institution-defined governance criteria.
Claim accuracy review
Exception rate review
Model drift monitoring
Pilot outcome reporting
Common questions

What pilot partners ask before integration.

"Can we verify without receiving raw financial data?"
Yes. PASSID returns scoped credential claims and verification metadata, not raw transaction feeds or financial statements. Your systems receive structured claim summaries only.
"Who makes the decision?"
The institution does. PASSID verifies credential claims. Your policy, risk, compliance, and operations teams own the final decision - not PASSID.
"Can we audit the verification?"
Verifier responses include token status, issuer signature state, freshness window, revocation state, and a unique audit ID. Institutions keep their own log of verification events.
"Can we start in sandbox before going live?"
Yes. Institutions test the full verify flow using sandbox credentials and synthetic demo tokens before any live rollout. Production access follows a pilot review.
Controlled pilot

Built for controlled pilots before production rollout.

PASSID is designed for institutions that want to test credential verification with sandbox credentials, scoped claims, audit metadata, and a clear sandbox-to-live review before any production deployment. No commitment before you have reviewed the results.

Test a sandbox verification
Or email hello@passid.io to discuss your use case.
Pilot validation areas
01
Sandbox token testingVerify flow
02
Claim schema reviewData model
03
Revocation and lifecycle testingToken control
04
Audit log and metadata reviewCompliance
05
Exception and edge-case handlingRisk review
06
Live-access approval and go-live reviewProduction
Credential signal graph
A financial signal graph for portable verification
PASSID maps verified accounts, remittance rails, savings behavior, salary flows, and institution attestations into signed credential claims. Instead of restarting from zero, users can present a verifier-ready token across markets.
PASSID Identity Mesh
Signed claims Multi-rail data Cross-border ready
Signal composition
Income stability
Cashflow discipline
Payment reliability
Fraud integrity
Compliance gate

From raw history to portable trust

Each node represents a verified behavior source. PASSID turns fragmented financial footprints into claim objects that lenders, banks, and platforms can review without receiving raw personal data.

Verifier flow
Token in. Signed claims out.
The institution receives a PASSID token, verifies signed claims, checks freshness and revocation, and keeps an audit trail. The verifier response is scoped to claim summaries and metadata, not raw financial data.

Verifier response walkthrough

Instead of sending statements, screenshots, and fragmented PDFs, the applicant shares a compact token. PASSID verifies token status, issuer signature, freshness, and revocation, then returns claim summaries for the institution's own policy workflow.

01/tokenAwaiting PASSID token
02/signatureIssuer signature not checked
03/lifecycleFreshness and revocation idle
04/outputNo verification response yet
PASSID token
Signed claims
Freshness check
Revocation check
Audit ID
Issuer signature
passid verifier
Standby
No token verified yet
The market problem

Verified credentials should travel with the person, not reset at every border.

1.4 billion mobile money users and hundreds of millions of cross-border workers carry real financial track records. Legacy credit systems cannot read them. The result: invisible borrowers for institutions — and locked-out users who have already proved themselves.

Portable trust pipeline issuer · holder · verifier
01
Signals become claimsIncome consistency, balance resilience, sanctions status, and freshness are translated into portable credential claims.
02
Claims become credentialsPASSID signs and packages those claims into a revocable, presentation-ready credential.
03
Institutions verify, then decideOne verification call returns signature status, audit metadata, and structured claim summaries - institutions keep their own policies and liability.
Step 01 · Arrival

A strong borrower lands in a new market and becomes invisible.

International students, migrant professionals, and globally mobile workers often arrive with savings history, repayment discipline, and active bank relationships — but traditional scoring systems fail to recognize any of it.

0local bureau history on day one
3+financial systems already used abroad
Weekslost to manual onboarding and documentation
Step 02 · Translation

PASSID converts fragmented signals into portable verified trust signals.

Instead of relying only on a domestic bureau file, institutions receive normalized behavior signals: income consistency, balance resilience, remittance patterns, savings cadence, and verified institutional attestations.

5core risk pillars structured for decisions
1portable credential and verifier response
APIverification for onboarding and credit access workflows
Step 03 · Verification

Banks, fintechs, and platforms verify financial trust without requesting raw data.

PASSID gives institutions a credential verification layer: signed claims, freshness windows, revocation state, and audit metadata — all without receiving financial statements or raw transaction feeds. Institutions apply their own onboarding and compliance policies.

Newcustomer segments become addressable
Lowermanual review overhead and KYC friction
Portableidentity persists across borders and rails
PASSID
Thank you — we'll be in touch.