VISA DIGITAL BENEFITS PLATFORM • SYSTEM DESIGN FOR CONFIGURATION OF CARD BENEFITS
Visa Digital Benefits Platform (VDBP) is an internal enterprise tool used by issuing banks and Visa administrators to configure cardholder benefits and packages at scale. When I joined the project, the system had a foundational problem: no organizational structure. Every variation of a benefit—different region, different card tier, different coverage limit—required creating an entirely new benefit record from scratch. Over time, the benefits library had become an unnavigable pile. Teams at issuing banks like Bradesco were slowing down, making errors, and losing confidence in the system.
My role was to design a way out of that.
Benefits configuration sits at the intersection of policy, money, and operational risk. A misconfigured benefit isn't an abstract UX failure—it can break cardholder entitlements across an entire region. That reality shaped every design decision: the goal wasn't just to make the system easier to use, it was to make it harder to break.
Before designing anything, I had to understand what I was actually designing for. VDBP is a many-to-many system: a single benefit can belong to multiple packages; a single package can contain dozens of benefits; a card product can carry multiple packages; and each of those relationships carries its own rules, states, and constraints. Change one thing in the right place, and it cascades correctly. Change it in the wrong place, and it quietly breaks something three levels away.
To get my head around this—and to give myself a framework that could hold up as the system grew—I organized everything into three categories: Objects, Attributes, and Actions.
Objects are the primary entities in the system: benefits, packages, tiers, card types, and the eligibility rules that govern them. Each is a discrete thing that can be created, configured, and related to other things.
Attributes are the properties that define an object: a benefit's coverage limit, geographic scope, currency, time period, approval state. But here's where it gets interesting—objects frequently become attributes of other objects. A benefit, itself a complex object with its own properties, becomes an attribute of a package. A card tier, which has its own rules and constraints, becomes an attribute of a benefit. The system is nested, and the nesting goes deep.
Actions are what users do: create, edit, add, approve, reject, publish, expire. But actions don't just happen and disappear—they leave state behind. An approval action transforms the approval state attribute of a benefit. A rejection creates an audit trail that becomes part of the object's history. Actions crystallize into attributes.
This framework wasn't just conceptual. It directly shaped how I organized the interface: what belongs in a menu view versus an overlay versus a detail page, what needs to be visible at a glance versus discoverable on demand, and where the guardrails needed to live.
The parent-child model was the project's founding premise—it existed before I was assigned to it. What I had to do was make it real in the interface, and solve every edge case that came with it.
The core idea: instead of creating a new benefit for every regional or tier-based variation, admins define a base benefit once. Child benefits inherit the parent's attributes automatically—coverage rules, eligibility logic, geographic constraints—and can selectively override only what needs to change. A grandchild benefit inherits from its parent, which inherited from its grandparent. The hierarchy is live, not copied.
This is where the Objects/Attributes/Actions framework became essential. Inheritance means that an attribute set on a parent object propagates silently down the tree. The interface had to make that propagation visible and trustworthy—users needed to know which attributes they owned and which they had inherited, and what the downstream consequences of changing either would be.
The risk was real: build the extension model wrong, and existing packages break. Cardholders lose benefits they're entitled to. Banks file complaints. We had to design the system so that extensions could only modify what was safe to modify—certain attributes were editable, others were locked at the parent level—and so that adding or removing a child benefit couldn't silently invalidate the package it belonged to.
That meant designing explicit guardrails, clear inheritance indicators, and conflict messaging that told admins exactly why something was blocked and what to do about it. Not every edge case was glamorous work. Most of it was grinding through scenarios until we were confident nothing could fall through.
The old model had no inheritance, no hierarchy, no shortcuts. If a benefit needed to work slightly differently for Brazilian cardholders versus Mexican ones, an admin created two separate benefit records—full stop. Multiply that across dozens of banks, hundreds of card products, and thousands of regional variations, and you get a library that nobody can navigate and everyone is afraid to touch.
The costs were real: duplicated work, slower approvals, and a growing risk that nobody knew which benefit record was the authoritative one.
We aligned on five outcomes:
The benefits and packages menus had to do real work. At Bradesco and other issuing banks, admins were processing approvals at volume—they needed to scan a list and know immediately what required attention, what was safe to publish, and what was stuck.
I added hierarchy and approval state as first-class information in the menu view. Base benefits and extensions are visually distinct. Status badges—Saved Draft, Pending Approval, Published, Expired, Rejected—are scannable at a glance. In Objects/Attributes/Actions terms: the menu surfaces the most decision-critical attributes of each object, so the action an admin needs to take is immediately obvious.
This was one of my ideas, and it became one of the most-cited improvements in user feedback.
Previously, reviewing a benefit or package meant opening the full detail page, locating the relevant data, making a judgment, then navigating back. For teams processing dozens of approvals, that context-switching added up fast.
The overlay pattern lets an admin see everything needed to make an approval decision—status, history, relationship hierarchy, key attributes—without leaving the menu. The action is available exactly where the object is being evaluated. Approve, reject, or flag for edit, all in place. Users reported that this alone sped up the approval workflow by 15–20%. At the volume Bradesco operates, that's meaningful.
In a many-to-many system with parent-child relationships, package inheritance, and approval states all operating simultaneously, it's easy to lose your bearings inside a detail view. The sidebar was my solution to that.
On benefit detail pages, the sidebar shows where you are in the object hierarchy—base or extension, which parent it belongs to, which packages include it. On package pages, it surfaces tier-level summaries and breaks down cost and responsibility between Visa and the issuer. It answers the question every admin needs answered before touching anything: "What is this object, what does it belong to, and what inherits from it?"
Benefits are governed by layered rules: eligibility tiers, coverage limits, currencies, time periods, regional constraints. Each of these is an attribute of the benefit object—and each can be inherited, overridden, or locked depending on where the benefit sits in the hierarchy. The design had to support that depth without making simple tasks feel complicated—and without giving admins enough rope to hang themselves.
Benefits needed to support multiple markets and supporting documentation. Additional language support and attachments were designed as first-class sections so admins could manage localized content and required documents without losing context.
Unhappy paths mattered as much as happy ones. Partial completion, missing documents, validation failures—enterprise workflows hit all of these. The UI needed to surface what went wrong and what to do next, clearly and without drama, so admins could resolve issues without losing their place or their nerve.
Packages are where benefits become "real" for cardholders—and where the many-to-many complexity becomes most acute. A package is itself an object, but it's also a container for benefit objects, each of which carries its own attribute set, inheritance chain, and approval state. The UI needed to show not only which benefits were included, but how they were inherited or cascaded from parent packages, and how optional bundles and cardholder choices affected the final structure.
Adding benefits isn't just selecting from a list. The system enforces rules to prevent conflicts—a child benefit can't be added if its parent is already included, because the child's attributes would be redundant or contradictory. These constraints were made visible in-context so users understand why something is blocked and exactly how to proceed, rather than hitting a wall with no explanation.
As VDBP matured, operational features were added to support real-world maintenance. Renewal reminders and email settings are one example: the product needed to handle time-based states and notifications without forcing admins out of their workflow.
The system got significantly more complex during the project—more tiers, more states, more edge cases—and the interface absorbed that complexity without becoming brittle. The Objects/Attributes/Actions framework held up. The guardrails held. The overlays worked. The sidebar kept people oriented when the underlying model was genuinely hard to reason about.
Most of all: we didn't break anything. In a system where a bad configuration can affect real cardholders at a major bank, that's not a small thing.
Before an admin publishes a change that cascades through packages and assignments, they should be able to see exactly what will be affected. A clear "what will change?" preview—before committing, not after—would make an already-safe system feel trustworthy in a way that's immediately legible. That's the next layer I'd go after.
LinkedIn
AngelList
Dribbble
Twitter
Pinterest
Medium
Behance
