Automating ASIC Compliance Through Self-Serve Investor Profiles
How I turned a read-only, support-heavy profile system into a self-serve experience, automating ASIC Form 484 compliance and eliminating the need for manual MongoDB edits.
Information Architecture
Logic Mapping
UX Auditing
Workshop Facilitation
COMPANY
Boulevard Global
INDUSTRY
Fintech B2B
TIMELINE
Aug 2022 – Feb 2023
ABOUT
Boulevard Global (now Liquidise) is a regulated share registry helping private companies manage equity and ASIC compliance. As the sole designer, I led the redesign of a broken, static profile system into a logic-driven self-service experience.
CHALLENGE
Every profile update required manual intervention. The CEO and Head of Product were editing production data directly and hand-filing ASIC forms for routine changes. On a team of 6, this wasn't sustainable.
TEAM
CEO, Head of Product, Product Manager, 2 Engineers, Product Designer (me)
IMPACT
For the first time, investors could manage their own profile data without contacting the team. Daily support requests almost completely disappeared, and roughly 10 hours of founding team time went back to building the product every week.
Preface
Look but don’t touch
Eight to ten update requests a day, every one ending with a founder editing a live financial database by hand.
Boulevard was built as a secure, digital source of truth for private share registries. To protect the integrity of legal records, the platform was strictly read-only for its two primary user groups: Investors and Company Administrators. On paper, this made sense. In practice, it created a system where users were completely powerless over their own data.
The problem compounded as the user base grew. What started as a careful design decision became an operational liability. Every data change, no matter how minor, had to be handled internally. The team wasn't just managing a product. They were managing a growing backlog of manual requests with no end in sight.
Four systemic blockers emerged:
Zero Autonomy
Users could not edit their own records. A simple address change or name correction became a permanent fixture they had no way to resolve themselves.
The MongoDB Risk
With no user-facing edit functionality, the CEO and Head of Product were directly editing production data in MongoDB to resolve requests. One wrong entry in a live financial database carried serious consequences.
Manual Regulatory Burden
In Australia, every name or address change is a legal event. The team had to manually process and file a Form 484 with ASIC for every routine update, pulling senior leadership away from higher-value work.
Interface Debt
The existing UI had no labels, no visual hierarchy, and no structure. Dense profile data was difficult to scan and understand, which increased confusion and drove even more support requests.
This wasn't an occasional inconvenience. The team was fielding 8 to 10 profile update requests every single day, each one requiring a manual MongoDB edit and, in many cases, an ASIC Form 484 filing.
The investor profile card. I scoped the first release to Owner and Contact, where every support request originated.
This case study covers the investor profile card only. I made a deliberate decision to scope this project to the Owner and Contact sections first, since that was where 100% of support requests were originating. The Shares and holdings data below is a separate system that did not require redesign.
" We were scaling the user base but also scaling a mountain of administrative debt. My job was to untangle the logic and design a system that gave users real control while keeping the platform compliant and the data clean. "
UX Audit
It looked like a missing edit button. It was a data ownership problem.
Profiles were never just individual or company. Six ownership structures were buried in flat, unlabelled data.
Before designing anything, I needed to understand why these profiles were so complex. On the surface it looked like a simple edit problem. But the deeper I looked, the more I found hidden logic that the existing UI had never accounted for.
Profiles weren't just "individual" or "company." There were joint owners, beneficiary structures, trust arrangements, and edge cases that varied depending on ownership type. None of this was visible or structured in the current interface. It was all buried in flat, unlabelled data blocks.
Auditing the Existing UI
I mapped my findings against Nielsen's heuristics. Three things stood out immediately.
Audited against Nielsen's heuristics: no labels, no hierarchy, no editability signals.
No labels, no hierarchy, no grouping.
Every piece of investor data sat in a single flat block. Owner details, contact information, and compliance data all at the same level, making it hard to find anything quickly.
Visual inconsistency
Everything else used a card-based layout. The investor profile did not, making the screen feel unfinished before a user even tried to interact with it.
No editability signals whatsoever.
No edit button, no hover states, no affordance of any kind. In a platform handling real financial data, that is not just a usability problem. It is a trust problem.
Defining the Six Profile Types
I ran a workshop with the Head of Product and PM to map out every investor profile type the platform needed to support. For each type we identified what data was required, what was missing from the current design, how ownership structure affected the fields shown, and which fields carried compliance implications. This gave us a shared foundation before a single wireframe was drawn.
Six investor types mapped in a workshop with the Head of Product and PM.
Mapping the Full Field Logic
With the profile types defined, I worked with the PM and Head of Product to map every field across all six types in detail. For each field we documented whether it was required for the first release, whether the user could edit it, and how it mapped to ASIC requirements.
TFN was scoped out of the first release to keep the initial interface focused on the core owner and contact details.
This wasn't just a design exercise. It became the single source of truth that engineering, product, and compliance could all work from.
Every field across all six types: required, editable, and how it maps to ASIC.
Iterations
What the first wireframe could not do
I put an early wireframe in front of the team specifically to find what it could not handle.
A flat card consistent with the rest of the platform: investor name, type, address, email, phone. Deliberately minimal, and put up to be broken.
Before committing to the full system, I presented an early wireframe to the team to pressure-test the direction. The layout was simple: a flat card consistent with the rest of the platform, showing the investor name, type, address, email, and phone number. Clean and deliberately minimal.
The first wireframe. Clean, consistent with the platform, and not scalable to six profile types.
The team responded positively to the direction, but the session surfaced three things the first version had not accounted for:
Multiple contacts were needed. Investors often needed more than one contact to manage their holdings.
Contacts needed to be invited directly from the card, rather than going elsewhere in the product.
The first investment date and beneficial status were missing entirely from the display view.
I observed that this layout was also not scalable to accommodate all 6 profile types. Each type would require a different layout. We needed a layout that would scale across all profile types with as few components as possible.
I incorporated all three pieces of feedback into the next version. The single contact row became a multi-contact table with an Add contact action and a Send Invitation link per row. I expanded the Owner section to include First invested date and Beneficial status.
The revised version: a multi-contact table, invitations per row, and the missing Owner fields.
Stakeholders signed off with one final addition: TFN to be included as an editable field for future feature compatibility. It was intentionally descoped from the first release as it was optional and not required for ASIC compliance at launch. The modular table structure meant adding it later would require no redesign.
That feedback loop, from first wireframe to stakeholder response to revised design, compressed what could have been weeks of back and forth into two focused sessions. It also gave the engineering team confidence that the designs they received had already been stress-tested by the people who knew the compliance requirements best.
Design
One component, six investor types
Rather than six layouts for six profile types, I built one that could become any of them.
With the profile logic mapped and the field rules defined, I had everything I needed to redesign the experience from the ground up. The goal wasn't just to add an edit button. It was to build a system that could handle six distinct investor types, enforce the right rules for each one, and make the whole thing feel simple to the person using it.
Individual, joint, and company profiles all needed different amounts of owner data. Beneficial and non-beneficial variations of each added another layer: non-beneficial profiles required an additional Beneficiary section showing the trust or SMSF name and ABN, while beneficial profiles did not.
Rather than build separate layouts for each combination, I used tables for the Owner and Contact sections.
One row for an individual owner, two for a joint investor. Same component.
Company profiles reuse the structure, with ACN/ARBN added.
Beneficiary visibility tied to Beneficial status, appending ATF to the investor name automatically.
The Beneficiary section visibility was tied directly to the Beneficial status field. When Beneficial is set to No the section appears, and the investor name is automatically appended with "ATF" followed by the beneficiary name, reflecting the legal trust structure. When Beneficial is set to Yes the section does not appear.
One component covering all six types, so a single fix applies everywhere.
Solving for Financial Jargon
During internal walkthroughs, terms like "Beneficial Status" were stopping users in their tracks. Rather than simplify the language and risk losing legal accuracy, I introduced the platform's first tooltip component.
Users could get an on-demand definition without leaving the flow. This addressed a real risk of abandonment in a context where confused users had no option but to call support.
The platform's first tooltip component, added so legal accuracy did not have to be simplified away.
Role-Based Editing
The edit form had to handle a fundamental tension. Investors needed enough control to update their own data without creating compliance risk, while admins needed full access to fields investors should never touch directly.
Field-level permissions: read-only for investors, editable for admins.
I solved this through field-level role permissions. Fields tied to legal ownership status appear as read-only for investors with a tooltip explaining why they cannot be changed. When an admin opens the same form those fields become editable.
The same form serving two roles without becoming two designs.
The same edit form served two different users without needing two separate designs. The structure communicated access levels without the system needing to explain them in words.
Handoff
Compliance logic breaks silently, so the handoff had to be exact
If engineering misread the logic for even one profile type, compliance would fail silently until a Form 484 went out wrong.
Dozens of field variations and compliance rules across six profile types meant a clean handoff was not optional.
Closing the Loop with Engineering
I ran a dedicated review session with the engineering team before a single line of code was written. We walked through the logic together, clarified ambiguous states, and caught several edge cases that would have caused validation errors in production. That session saved us at least a week of back-and-forth during QA.
Organising the Handoff
I structured the Figma files by ownership type across rows and flow type across columns. This meant engineers could go directly to the exact screen they needed without reverse-engineering the logic from a sea of screens. Every state, every edge case, and every field variation was accounted for and easy to find.
Figma organised by ownership type across rows and flow type across columns.
Writing the Tickets
I worked with the PM to write Jira tickets for each investor type and user state. Rather than leaving interpretation to the developer, each ticket included the field rules, visibility logic, and expected behaviour for every variation. This significantly reduced the number of clarification requests during the build.
Jira tickets carrying field rules and visibility logic, not just screens.
Testing
Every type, every role, before anything went live
Role-based rules and compliance logic give you a lot of ways to break quietly.
I partnered with the PM and Head of Product to run internal QA before anything went live.
What We Tested
We worked through every investor type end to end, checking that the right fields appeared for the right roles, that form validation behaved correctly, and that editable fields saved accurately.
We also stress-tested the edge cases we had mapped in the audit, joint ownership structures, beneficiary rules, and trust arrangements, to make sure the logic held across the full range of scenarios.
What We Caught
QA surfaced several small but important issues before launch. None were critical but any one of them left unresolved would have created data inconsistencies in a live financial registry. Catching them before production was the point.
Outcome
The CEO stopped editing the database
Investors could finally edit their own records, and the founding team got out of the database.
The system launched successfully across the full platform after internal QA validation. Here is what changed.
Based on the support team's assessment post-launch, profile-related tickets had almost completely disappeared.
At 15 to 20 minutes per request, profile admin was consuming roughly 2 hours of the team's time every day before launch. That time went back to building the product.
The CEO, Head of Product, and PM were no longer editing production records directly. The risk of a senior team member accidentally corrupting live financial data was eliminated entirely.
Name and address changes that previously required manual regulatory filings were now handled by the system. Compliance became a byproduct of using the product correctly, not an extra step.
Every Form 484 the system filed after launch was filed correctly. For a compliance feature that is the outcome that matters most, and the one nobody notices when it works.
Reflection
Looking back
The interface was the small part. Six investor types and their field rules were the work.
This project looked simple on the surface. A profile page. An edit button. But the real work was in the logic underneath, mapping six investor types, defining field rules, and making sure compliance was built into the system rather than bolted on after the fact.
Logic before layouts
The most valuable time I spent on this project was before I opened Figma. The workshop with the Head of Product and PM, and the field mapping exercise that followed, gave the entire team a shared understanding of a system that nobody had ever fully documented. That foundation is what made the design, the build, and the QA all go smoothly.
Unglamorous work has strategic value
Eliminating a daily flood of manual support requests didn't require a flashy redesign. It required understanding why the system was broken and fixing the structure, not just the surface. The CEO and Head of Product got hours back every week. That's a business outcome, not just a UX improvement.
What I’d do differently
The assurance was manual, and it should not have been. We worked through every investor type and role by hand, caught several issues before launch, and the filings the system produced afterwards were correct. It held. But it held because people were careful, not because the system checked itself, and a manual pass only ever finds what you thought to look for.
On a system where a wrong field quietly becomes a wrong regulatory filing, I would push for automated validation on the compliance rules themselves, so the logic is checked on every change rather than once before launch. Designing the rules and then testing them by eye is the weakest part of what we built.
The strategy at that stage was ship first and fix later, and for a company that size and that runway it was the right call. It is why I would argue the exception rather than the rule. Compliance logic is the one place where fixing later means someone external finds it before you do.