Germaine Chin

Case studies

Four projects from my work at Phillip Nova, a regulated brokerage in Singapore. Each one shows a different part of how I work as a Product Manager. Figures are rounded, and confidential details are left out.

Retiring a legacy onboarding platform

Once our new account-opening platform was live, the old one still had thousands of applications sitting in it. I wrote the plan to switch it off safely in 60 days, without building anything new.

My role
Product Manager, owner of the sunset plan
Worked with
IT, the account approval team, Customer Service and Compliance
Constraints
MAS guidance on using NRIC numbers for login and PDF passwords, plus audit retention rules
Result
Only about 1 in 8 records needed a decision, and every one of them had a clear rule

This follows on from rebuilding trading account onboarding. Launching the new platform was half the job. The other half was closing the old one without hurting anyone still in it.

The problem

The old platform held about 8,000 applications going back to 2019. Nobody was sure how many were still "live", so switching it off felt risky. Meanwhile it still relied on NRIC-based flows that new MAS guidance was moving away from. Every extra month it stayed up extended that exposure.

What I did

  1. Sized the real problem first

    I pulled every record and grouped it by status. Nearly 9 in 10 were already finished: approved, rejected or expired. That turned "8,000 applications" into about 1,000 that actually needed a decision.

  2. Picked the right signal

    I sorted the remaining records by when anyone last touched them, not when they were created. An application worked on last year isn't comparable to one abandoned in 2020. Almost all had sat untouched for more than a year. Only a handful were recent.

  3. Wrote simple rules for each group

    Stale records were expired on day one. The few recent ones got a personal email and 30 days to reply. The single record with activity this year was handled by hand.

  4. Set a timeline with owners

    Freeze new work a week before. Redirect all traffic on day zero. Switch the client site off at day 60, keep a read-only admin view for a year for audits, then archive.

How about 8,000 old applications became three simple rules A bar shows about 8,000 applications. Nearly 9 in 10 were already finished and needed no action. About 1,000 needed a decision. Those were sorted by last activity, then split into three groups: almost all were untouched for over a year and were expired on day one; a handful touched in the last year got a personal email and 30 days to reply; one active this year was handled by hand. A timeline runs from a freeze one week before, to redirecting traffic on day 0, switching the client site off on day 60, and archiving after 12 months. Left out on purpose: migrating old applications, contacting approved clients and hard-deleting records. About 8,000 applications on the old platform Nearly 9 in 10 were already finished Approved, rejected or expired. No action needed. About 1,000 needed a decision An application worked on last year isn’t comparable to one abandoned in 2020. Sorted by last activity Not by the date the application was created Untouched for over a year Expired on day one Almost all of them Touched in the last year Personal email A handful, with 30 days to reply Active this year Handled by hand A single record The 60-day switch-off Day −7 Freeze new work Day 0 Redirect all traffic Day 1 Expire stale records Day 30 Reply deadline Day 60 Client site off, admin read-only +12 months Archive Left out on purpose Migrating old applications Contacting approved clients Hard-deleting records
Most of the plan was a sorting exercise: size the real problem, pick the right signal, then write one rule per group.

Key decisions

Reuse what already exists. We already had an "Expired" status that stops reminder emails, keeps the record for audit and lets the client apply again later. Using it meant no new states and no new tooling.

Don't migrate old applications. The two platforms store data differently, and identity checks on anything over a year old would be out of date anyway. The engineering effort would have served about six people.

Leave approved clients alone. They are already customers. Contacting them would create confusion and churn risk for no benefit.

Never hard-delete. Retention rules require records to stay, and a soft end state keeps every application reconstructable.

Result

  • A 60-day plan instead of an open-ended migration project.
  • A risk register covering the obvious worry, expiring someone who is still active, with a filter that no active applicant could fall into.
  • A written record we could show as evidence that the NRIC exposure was being closed on a fixed timeline.

What this shows

Most of the work was deciding what not to do. A clear number and a clear rule made a scary-sounding change easy for every team to agree to.

Making market data subscriptions self-serve

Clients were calling support every day just to add or change their market data. I ran discovery with five internal teams, then deliberately scoped the first phase to the one problem we could fix fastest.

My role
Product Manager, from discovery to requirements
Worked with
Business units, Customer Service, IT support, the account approval team, the market data team and a product designer
Constraints
No changes to approval rules, billing or back-office terminology in this phase
Status
Requirements and designs in progress for Q4 2026

The problem

To use live prices from an exchange, a client needs a market data subscription. Managing one in our client portal meant moving between five separate pages, reading admin terms like "Apply New Product/Platform", and submitting a separate form for every exchange. Clients asked support for help so often that it had become a daily task.

I am very confused whenever I want to manage my market data subscription. Where do I go? There are so many pages.

A client, passed on by our support team

Discovery

I ran separate sessions with each team that touches market data, because each saw a different slice. Business units voted on pain points. Customer Service listed their most common questions. IT support explained how approvals and page visibility worked. The market data team confirmed which rules were regulatory and which were just history. I also reviewed how competing brokers handle the same journey.

The most useful finding: the rule that clients must submit one form per exchange wasn't a regulatory requirement. It was a leftover from an older system. That made the biggest complaint fixable.

Scoping

Discovery surfaced a long list: auto-approval, billing changes, dormant accounts, risk classification. Doing it all at once would have meant months of back-office work before clients saw anything. So I split it. Phase one fixes the confusing experience only, without touching business rules. The heavier changes are written up for later phases, each with a reason.

From five teams’ input to one finding and a split scope Six inputs feed discovery: business units, Customer Service, IT support, the account approval team, the market data team and a review of competing brokers. They lead to one finding: submitting one form per exchange was a leftover from an older system, not a regulatory requirement. The scope then splits in two. Phase one fixes the experience without touching business rules: one overview page, a cart with one submission, fees shown upfront, only relevant actions, clear reasons when blocked, and removing a broken two-factor toggle. Later phases hold auto-approval, billing changes, dormant accounts and risk classification. Who I asked What changed the scope How I split it Business units Voted on pain points Customer Service Most common client questions IT support Approvals and page visibility Account approval team How clients are classified Market data team Which rules are regulatory Competing brokers How others handle the journey One form per exchange was a leftover from an older system, not a regulatory requirement. That made the biggest complaint fixable. Phase one Fix the confusing experience, business rules untouched One overview page Cart with one submission Fees shown upfront Only relevant actions Clear reasons if blocked Broken 2FA toggle removed Later phases Written up, each with a reason Auto-approval Billing changes Dormant accounts Risk classification
Discovery produced a long list. One finding decided what went into phase one and what waited.

What phase one covers

  • One overview page showing what you're subscribed to, what it costs and the status of any request.
  • A cart so you can add or remove several exchanges and submit once, with one declaration instead of up to five.
  • Fees shown upfront, with the platform fee and exchange fee labelled separately.
  • Only relevant actions: options that don't apply to a client's platform are hidden, not just disabled.
  • Clear reasons when something is blocked, linking straight to the page that fixes it.
  • Removing a broken toggle: the flow asked clients to opt in or out of two-factor authentication, which is mandatory. Choosing "No" left them stuck.

How we'll measure it

  • Fewer market data calls, emails and chats to support teams, against a baseline taken before launch.
  • Fewer steps to complete common tasks.
  • A client can answer "What am I subscribed to, what does it cost, and where is my request?" from the portal alone.

What this shows

Good research produces more ideas than a team can ship. The value is in separating what's truly required from what's habit, then picking the smallest first step that clients will notice.

One login across three trading platforms

Clients had separate logins for our client portal, our trading app and MT5, and some statements were protected with their NRIC number. I wrote the requirements for one shared login, managed by a central service.

My role
Product Manager, owner of the client portal requirements
Worked with
Engineering, IT support, the identity service team and the back-office team
Constraints
MAS guidance on NRIC use, existing password and lockout policies, and an MT5 interface that only accepts plain-text passwords
Status
Requirements ready for technical assessment

The problem

A new client could end up with three different IDs and three passwords. Each system had its own reset flow and its own admin screen. Statements were sent as PDFs locked with the client's NRIC number, which regulators were moving away from. Support teams spent time working out which login a client was even talking about.

Goals

  • One login ID and password for the client portal and trading app, checked by a single credential service.
  • No NRIC-based PDF passwords. Statements are viewed after logging in instead.
  • A clear path from approval to first trade.

What I specified

  • Activation: a single-use link that expires after 72 hours, with separate pages for expired, invalid and already-activated links, so nobody hits a dead end.
  • Recovery: separate flows for a forgotten password and a forgotten login ID, both checked against the registered email.
  • A getting-started page that changes depending on which platforms the client opened.
  • MT5 activation: a one-time temporary password generated on demand, never stored in plain text, with a reminder until it's used.
  • Admin tools: support staff can see activation status, search by the new ID, and resend links.
  • Edge cases: joint accounts, accounts created by hand, and clients sharing a name and email.
Three logins become one, with a page for every activation state Before: the client portal, the trading app and MT5 each had their own ID, password and reset flow, and statements were PDFs locked with the client’s NRIC number. After: one login ID and password, checked by a central credential service, opens the client portal and the trading app. MT5 is activated from the portal with a one-time temporary password, and statements are viewed after logging in. The activation link has four states and each leads somewhere: a valid link lets the client set a password and go to getting started; an expired link sends a new one; an invalid link lets the client request a new one; an already-activated link goes to getting started. Kept as is: one-time codes and the three-strike lockout. Later phases: third-party PDF passwords and real-time sync with the back office. Before After Client portal Own ID, password and reset flow Trading app Own ID, password and reset flow MT5 Own ID, password and reset flow Statements PDF locked with the client’s NRIC number One login ID and password Checked by a central credential service Client portal Trading app MT5 One-time temporary password from the portal Statements Viewed after logging in, no PDF password Activation link: every state leads somewhere Valid link Single use, 72 hours Set a password Then getting started Expired link After 72 hours New link emailed No call to support Invalid link Broken or already used Request a new link Old links cancelled Already activated Link clicked again Getting started No second activation Kept as is One-time codes Three-strike lockout Later phases Third-party PDF passwords Real-time sync with the back office
Requirements were written state by state, so engineers could estimate against every unhappy path.

Key decisions

Keep the parts that already work. One-time codes and the three-strike lockout stayed in place. Changing them would have meant retraining clients and support teams for no real gain.

Leave some work out on purpose. Third-party PDF passwords and real-time sync with the back office were split into later phases, so the core login could move forward.

What this shows

Identity work touches every system, so most of the job is mapping who depends on what. I wrote requirements engineers could estimate against, with an answer for every unhappy path.

Fixing a dead end in the eligibility check

Applicants opening a forex and CFD account had to pass a knowledge check first. Those who hadn't done it yet got confusing messages and no way to finish. I redesigned the step around what support staff were hearing.

My role
Product Manager, with a product designer
Worked with
Customer Service, the account approval team and engineering
Constraints
Singapore rules requiring proof of product knowledge before trading forex or CFDs
Result
Applicants can now finish the check after submitting, without going back

The problem

Before trading forex or CFDs, clients in Singapore must show they understand the products, usually by passing an industry quiz. If an applicant hadn't passed it yet, our form gave a generic message that assumed they already had portal access. Many didn't know whether they were eligible or what to do next, so they called support. Some gave up at the last step.

Evidence

Support and approval staff spoke to these applicants every day, so I started with them. They pointed to wording that implied a client was ineligible for everything when only one product was blocked. They also pointed to a "Continue" button that led clients to expect an upload page that didn't exist.

What changed

  • Clear wording that explains which product is blocked and why.
  • Separate checkboxes for each product and each completed module, with their own pass dates, instead of one combined answer.
  • A link to the official learning module, and the option to finish it later.
  • A new section on the final page so applicants can record their quiz result there, without going back and losing their place.
  • The same rules applied when staff send an application back for corrections.
The eligibility step before and after the fix The work started with support and approval staff, who pointed to the wording and button that confused applicants. Before: an applicant who had not passed the quiz saw a generic message that read as if every product was blocked, then a Continue button that suggested an upload page that did not exist, and ended up calling support or giving up. After: the applicant sees clear wording about which product is blocked and why, gets a link to the official learning module and can finish it later, submits the application, records the quiz result on the final page, and completes the check without going back. Left out on purpose: certificate uploads, because the approval team already verifies results through the industry portal. Started with the people hearing it every day Support and approval staff pointed to the exact wording and button that confused applicants Before After Applicant hasn’t passed the quiz yet Generic message Reads as if every product is blocked “Continue” button Suggests an upload page that doesn’t exist Calls support, or gives up One step before finishing Applicant hasn’t passed the quiz yet Clear wording Which product is blocked, and why Link to the official learning module Can be finished later Submits the application Keeps their place Records the result on the final page Separate pass date for each module Eligibility check complete Without going back or calling support Left out on purpose: certificate uploads Support asked for them. The approval team already verifies results through the industry portal, so an upload would add work without adding certainty.
The same applicant, before and after. The fix sits exactly where front-line staff said people got stuck.

What I left out

Support asked for certificate uploads. The approval team already verifies results through the industry portal, so an upload would add work without adding certainty. I explained this to both teams and left it out.

How we'll measure it

  • Fewer eligibility-related calls to support.
  • Fewer applicants dropping off at the final step.
  • More eligibility declarations completed without staff help.

What this shows

Front-line teams hear about a problem long before it shows up in a dashboard. Listening to them made a small fix land in exactly the right place.