SureTAG - Pay a name, not an account number
A financial identity network that resolves a human-readable alias into the right verified payment destination.
TIMELINE
2026
TEAM
Independent product exploration
IMPACT
Designed a human-readable payment identity that can resolve across multiple destinations
Role & Impact
- Designed a human-readable payment identity that can resolve across multiple destinations
- Separated a public alias from the canonical Finclusion identity beneath it
- Made recipient resolution, route selection, consent, and verification visible at consequential moments
- Built a functional sandbox covering personal, business, developer, partner, and admin points of view
Product walkthrough
The connected experience in motion
The problem with paying routing details
Account numbers, wallet addresses, and institution-specific handles make people manage routing details that belong to the payment network. SureTAG explores a portable financial identity: one memorable name that can resolve to the correct destination without hiding who will receive the money.
One name, the right destination
Designing identity before interface
Discovery & Stakeholder Alignment
The design challenge was to make an alias feel simpler than account details without turning it into an ambiguous username. The product therefore treats recipient resolution as a trust moment: the interface must confirm the person, show the route when it matters, and prevent familiarity from becoming carelessness.
Research & Validation
I mapped alias systems, payment handles, wallets, bank beneficiaries, and identity verification into one end-to-end transaction model. The strongest distinction was between the name people share and the stable identity the network uses to maintain continuity and accountability.
Framework Development
SureTAG is an identity-led network rather than a feature inside one wallet. A canonical Finclusion ID can hold multiple authorized destinations, while role-specific products use the same resolution, verification, consent, and audit primitives.
One network, five points of view
Favourite Screens (Highlights)
- •Personal home showing identity, wallets, payment mix, and recent activity
- •Recipient search and resolution before payment confirmation
- •Destination management across currencies and account types
- •Business, developer, partner, and administrative network views
Personal identity
A person's SureTAG, wallets, activity, and payment actions sit inside one identity-led workspace.
Business and partner use
Organizations can use the same resolution model for collections, payouts, and destination ownership without recreating identity.
Developer and admin operations
Integration and governance tools expose network state, resolution evidence, and operational controls for the teams responsible for the system.
Trust moments and sandbox boundaries
The live product is a functional sandbox. Internal Finclusion ledger flows are demonstrated; external payment rails and integrations remain simulated. The interface does not claim production connectivity or verified transaction volume.
Where the identity network goes next
The next phase would test recipient resolution with real users, formalize recovery and dispute paths, and connect the identity model to verified payment rails under production security and compliance controls.
Insights & Lessons
What Worked:
- •Separating the shared alias from canonical identity kept the simple surface technically durable
- •Making recipient resolution explicit preserved trust while reducing routing work
- •Multiple role views proved the concept could operate as shared infrastructure
What I Learned:
- •Hiding complexity should never hide responsibility
- •A payment identity is useful only when recovery, consent, and destination ownership are clear
- •The confirmation moment carries more trust weight than the search interaction
If I Could Do It Again:
I would pressure-test collisions, impersonation, recovery, and cross-border route exceptions before expanding the surface area.
Next Project