PTI Comparisons
Portable Trust Infrastructure (PTI) is an orchestration and composition layer for trust. It does not compete with identity providers, KYC vendors, credit bureaus, or fraud engines on their own terms — it connects their outputs into context-scoped, portable, explainable trust intelligence that institutions can consume at decision time.
What these pages are
Vendor-neutral explanations of how PTI complements existing trust technologies — what each layer solves, what PTI adds, and how they compose in production architectures.
What these pages are not
Product comparisons, feature matrices, or replacement guides. PTI assumes you will keep your IdP, KYC stack, bureau feeds, and fraud tools — and orchestrate them through a portable trust fabric.
The composability thesis
Most institutions already operate a trust stack: identity resolution, authentication, authorization, KYC/AML screening, bureau pulls, fraud scoring, and policy engines. Each component produces valuable signals. The structural failure is not the components — it is the absence of infrastructure that:
- Assigns a portable subject identifier (
pti_id) across partner and institution boundaries - Scopes signals to life-area contexts (lending, rental, employment, merchant, …) instead of collapsing them into one opaque score
- Preserves provenance so every outcome traces to attributable evidence
- Exposes programmatic trust lookup with explainability suitable for audit and adverse-action workflows
PTI fills that gap. See Problems with Existing Systems and Core Design Principles.
Comparison catalogue
| Technology | Primary job | What PTI adds |
|---|---|---|
| Identity systems | Resolve who a subject is | Portable pti_id, cross-partner entity linking |
| Authentication | Prove session authenticity | Trust event attribution after auth succeeds |
| Authorization | Enforce access policy | Context-scoped entitlements for trust data |
| KYC | Verify identity at onboarding | KYC outcomes as attestable trust signals |
| AML | Detect money-laundering risk | Screening results in compliance lens context |
| Credit bureaus | Formal credit history files | Non-bureau trust signals + context isolation |
| Open banking | Consented financial data access | Cash-flow signals scoped to lending context |
| Verifiable credentials | Cryptographically signed claims | VC issuance and verification as trust evidence |
| Digital identity | National or federated ID programs | Sovereign ID as input; PTI as trust exchange layer |
| Fraud systems | Real-time transaction fraud | Fraud flags as signals; PTI for cross-context trust |
| Risk engines | Institution policy and scoring | External intelligence envelope + explainability |
| Reputation systems | Platform ratings and reviews | Community signals with governance and provenance |
| Digital public infrastructure | Shared rails (payments, ID, data) | Trust as a programmable DPI layer |
| Knowledge graphs | Entity-relationship analytics | Trust graph model with context-scoped edges |
How to read each page
Every comparison follows the same structure:
- What the technology is — neutral definition
- What problem it solves — the job it was built for
- What PTI adds — orchestration, portability, context-scoping
- How they compose together — reference integration pattern
- When to use each — decision guidance for architects
- Related PTI spec/RFC links — normative references
Architectural placement
Start here by role
| Role | Recommended reading order |
|---|---|
| Architect / CTO | Identity → Digital identity → Credit bureaus → Risk engines |
| Compliance / AML | KYC → AML → Verifiable credentials |
| Platform / fintech engineer | Authentication → Authorization → Open banking → Fraud systems |
| Policy / DPI strategist | Digital public infrastructure → Knowledge graphs → Reputation systems |