Complying with Know Your Customer and Anti Money Laundering regulations is hugely complicated and expensive for financial institutions, and burdensome for their customers. Nate Soffio, Co-Founder and CEO of Portabl, believes that the solution lies in secure, interoperable data - enabled by verifiable credentials. In this webinar, he explains why it is such a thorny problem, how open banking needs to evolve to more of a “tap to prove” model as organizations increasingly need continuous identity assurance, and why despite describing the task as “playing SSI on ‘hard mode’”, he believes building a “compound startup” is the best way to get the job done.

3. The state of open banking,
regulations, and the
intersection of SSI and
KYC.

4. Open banking's identity problem
From screen scraping, to APIs, to tokenized access — an unfulfilled quest for secure interoperability
Agenda
Acronym bingo: KYC/AML meets SSI, VCs, and DIDs
Portabl: applied SSI for open banking & payments
It's not just about KYC and onboarding — toward uniform, user-first lifecycle standards
"Tap to Prove"/"Tap to issue": Semi-Sovereign Identity & compliance
Putting Portabl in context of the fraud and AML landscape, and how we're building trusted networks
Treating Financial ID as a "compound startup"
What's on our radar, and how businesses and developers get started
About Portabl
What are we building & what gets us out of bed in the morning

5. Mission
Simplify financial access & trust by powering reusable
identities & verifiable identity networks.
Vision
Universal financial identity for all.
Say hello to Portabl
Sharable identity at the speed of payments

6. We collapse KYC, authentication,
aggregation, and ID management into a
vertical set of identity APIs and web tools.
Users control reusable identity, account,
and payment credentials and share them
as needed across accounts—this
supports reputation building and trust that
travels.
What are we doing?
Open banking identity that's
real-time, user-controlled,
composable, and reusable
on-demand from account
opening to account close.

7. 2. Credential configuration
Configure APIs and widgets and
manage users in a single console
• Workspace/ Console
Home
4. Dashboard
5. User Management & recordkeeping
Developer Tooling
3. Drop in data sync widget

8. 1. Open banking's identity problem
The evolution of interop & permissions
Identity is complicated — it's no one agency's or business unit's job
• KYC vs CIP vs EDD
• CFPB, SAFE banking, OCC, FinCEN, etc.
Defining & conveying data has taken many forms
• Screen scraping
• APIs
• Token based access
• Lookup services
• ______?
Whether we like to admit it or not, open banking already relies on trusting "someone else's" data
• Aggregators
• Consortia
• Standards bodies (OFDSS, FDX)

9. 2. Applied SSI for Open Banking
Building the best of provider-verified data with user-first form factors
Bank verified data will always be needed, but
we should expect the scope to keep expanding
• Lots of economic activity outside happens outside of a
checking account
• "Data exhaust"
• We've learned how to tap into some of this for things
like credit underwriting
There's a long way to go
• New types of data for financial access and mobility
• New way to establish and maintain trust
Verifiable Credentials are a form factor that can do a
LOT of heavy lifting
• Standardize the interop of identity, suitability, and (some) account
attributes...not to mention anti-fraud signals
• Onboarding and origination
⚬ Treat new users like known ones
⚬ Avoid form fill and attrition
⚬ Add privacy preservation through flexible ways to prove things
• Offload PII risk
⚬ Record retention vs record access
⚬ Known & trusted bindings without 'oversharing'
• Lifecycle maintenance
⚬ Reconfirmations & refresh
Despite progress — open questions remain about privacy, ownership, security, and mobility. Treating SSI
methods as open banking data primitives begins to connect the dots.

10. 3. Open Banking Revisited
SSI x Open Banking = Semi Sovereign Identity
Road ahead: a balancing act between smarter, more frequent "checks" and "trust that travels" with the user
• institutions and service providers need to be empowered to become certificate authorities for consumers — extend the bank-verified
model to be X-verified.
• Consumers need to be brought to the table in ways that go far beyond allowing Plaid to log into your bank and hold that connection
• Issuer-holder-verifier model probably has at least 4 nodes, not three, to support a 'tap to prove' future
• Issuer, Holder, Verifier, Broadcaster, Registry Keeper
VCs and DIDs are useful for both point-in-time trust as well as longitudinal trust, so they also have a huge
role in reshaping what some call continuous identity, FKA refresh/ ongoing monitoring.
• This is grounds for frustration and anger for many self-sovereign maxis
• Hot take: true self sovereignty is incompatible with the regulated financial system—attributes are checked & consumed
more than ever
⚬ Financial system = set of social and legal contracts
⚬ example: GDPR makes for the same allowances for anti financial crime.
⚬ example: AML regs 314(a) and 314(b)
⚬ RTP needs RTI(dentity)

11. Financial ID touches the entire lifecycle — any solution must necessarily be a
'Compound Startup'
Auth
KYC
CIP
Refresh
Step-Up
Personalization
Loyalty
& Affiliates
4. On "Compound Startups"
'Moving open banking to the 'Tap to Prove' age means providing
a toolkit that makes business sense for the whole lifecycle
• Combine point solutions to solves for an “over-tooled” problem space.
• Have a common UX with shared components
• Have a foundational data layer
• Reduce complexity and costs for their customers
• Solve a coordination problem across systems (or agents)
P2P
T2P can be used contextually to overhaul different lifecycle events
• verify more, faster, and for less
• protect users and verify transactions
• unlock personalization and affiliate experiences
• reduce compliance burden by effectively subscribing to wallets