MarketGuard

AML and KYT compliance platform for crypto businesses – built from scratch with FinchTrade AG and shipped as marketguard.io. A multi-tenant B2B product with separate Compliance, Product manager, and CEO roles, each with its own view of the same case.

Role
Sole product designer, end-to-end
Scope
Research, IA, user portal, design system, website, brand communications
Domain
B2B fintech – AML / KYT compliance
Period
FinchTrade AG, Zug – MarketGuard built from late 2022 to May 2023
Team
16 people, same as FinchTrade
324 → 68 minActivation time, from signup to first completed check, 79% faster
26 → 2 minManual rework per case for the Compliance officer, 92% less
61NPS, B2B onboarding survey, 64 responses
Ilia Drozdov

“Kirill has proven to be not only a good designer but a person who tries to understand the essence and the value of a product.”

Ilia Drozdov, CFA

Co-Founder at Finery Markets · Recommendation on LinkedIn

Context

MarketGuard started the moment FTX collapsed. Overnight every crypto business around us understood it needed real AML controls rather than a policy document, and FinchTrade AG already ran a liquidity desk with that problem of its own – so the compliance tooling the desk needed internally became a product the company could sell.

That origin set the constraints. Buyers were arriving under regulatory pressure, not out of curiosity, so the product had to prove coverage before it proved usability. And it had to serve three people at once: the CEO signing off, the Product manager integrating it, and the Compliance officer living in it every day.

Role and scope

Sole product designer, end-to-end: discovery, user research, information architecture, UX and UI, the design system, the product website, and brand communications. I worked directly with the CEO, the CPO, and the compliance side of the business – CCO, MLRO, and AML officers – who were both the stakeholders and the users of what I designed.

I started from the user-goals list the stakeholders had, then checked it against the market: competitive research across B2C2, Wintermute, Flowdesk, CoinAlpha, Saddle, and ElixirTech, and more than 20 jobs-to-be-done interviews with people already using those solutions. Their needs and pains became the product requirements list for the MVP – then personas, information architecture, prototypes, A/B tests, and qualitative and quantitative surveys on top of the live product.

Insights that changed the product

The spine of the case: what the research found, what it changed in the interface, and what that produced.

Insight 1 – three buyers, three definitions of “good”

What research found
The CEO buys to avoid a fine and never opens the product again; the Product manager evaluates it once, mostly on the API; the Compliance officer lives in it daily and is the only one who judges it on the work itself.
What changed in the product
The portal splits into role-specific views over one shared case, instead of one screen trying to satisfy all three.
What it produced
There is no number for this one on its own: the role split shipped as part of the MVP, not as an experiment. The closest evidence is the testing that followed – 100% task completion in the repeat round and 90% satisfaction on the hardest flow.

Insight 2 – coverage is the first question, usability the second

What research found
Buyers arrived under regulatory pressure. In the interviews, the opening questions were about coverage – countries, blockchains, tokens, banks – and only then about how the work gets done.
What changed in the product
The website answers coverage on the surface: navigation by use case, a coverage matrix in pricing, an FAQ that states limits.
What it produced
No number of its own – the site went live as one piece, not as a test.

User portal

Three roles read the same case with different stakes: the CEO needs a decision he can defend to a regulator, the Product manager needs the integration to hold, and the Compliance officer has to justify every approval months later. The portal gives each of them a view over one shared case instead of one screen trying to serve all three.

Product overview: transaction monitoring, the screen the Compliance officer opens first every morning
Onboarding queue with statuses down the left rail
Onboarding queue: every company in the pipeline with the one status that matters next, so the officer works a list rather than hunting for what is due
Applicant detail with beneficiaries, documents and their review states
Applicant detail: beneficiaries, documents, and rejection reasons in one view – the officer approves or rejects without leaving the case
KYT cases list with transaction risk levels
KYT cases: transactions grouped by client and risk level, with the decision the Compliance officer has to defend later attached to each

Product website

The portal splits by role; the site does the opposite. Everything is on the surface at once – the main use cases as tabs, the integrations list, release notes, pricing – because all three buyers land on the same page and each needs a different part of it: the CEO checks who stands behind the product, the Product manager reads the integrations and release notes, and the Compliance officer looks for coverage. Navigation is organised by use case so each of them goes straight to their own question instead of through a feature tour.

Two pages carry the coverage question. The matrix in pricing states what each plan includes and what is still coming, so a buyer sees the gaps before a sales call rather than after one. The FAQ lists the countries, blockchains, and tokens as they stand, and names what is not supported instead of leaving it out.

Home page of the product website, desktop
Sitemap first: navigation organised by use case – client onboarding, transaction monitoring, treasury – because that is how buyers describe their problem
Home page on mobile
FAQ page listing supported countries, blockchains, and tokens, desktop
The FAQ carries the coverage question: supported countries, blockchains, and tokens, spelled out rather than promised – with the section nav riding along the page the way it does live
FAQ page on mobile
Pricing page with the feature matrix, desktop
Pricing states coverage as a matrix – what each plan includes and what is still coming – and ends on the same next step as every other page: book a demo
Pricing page on mobile

Design system

The system had to hold two products in one language and, hardest of all, compliance tables: dozens of columns an officer needs at a glance. Foundations sit on a 4×4 module, and every component is documented with its states, so a dense table stays readable at any width.

Design system foundations: atoms, molecules, organisms, the 4×4 module and component states
Foundations on a 4×4 module – grid, colour, typography, and icons with optical compensation
Design system components published in Storybook
Each component documented as it behaves – variants, states, live examples

Communication design

Buyers first meet the company through a LinkedIn post, a survey invitation, or a conference stand, and in a regulated market, the tone must signal control rather than momentum. One template system covers launch posts, product updates, survey invitations, and conference materials, so every touch reads as the same company.

LinkedIn company page and social post templates
Company page and post templates

Results

I built the admin panel onboarding flow from scratch and extended it, cutting activation time from 324 to 68 minutes – 79% – and cutting the Compliance officer's manual rework per case from 26 to 2 minutes – lowering the cost of onboarding an entity without adding review headcount. NPS 61 on the B2B onboarding survey, from 64 responses.

How the numbers were measured

Metric How it was measured
Activation time The clock runs from the start of registration, through document submission, to the final step of onboarding. The same flow serves both products, so the figure is shared with the FinchTrade case.
NPS Surveyed among companies that completed onboarding, not among visitors.
Bounce and abandoned registrations Same web analytics as the rest of the product, tracked together: leaving the site, and starting onboarding without finishing it.
A/B tests Measured on the same axis as activation: time to complete, and how far a company got through registration and document submission before dropping out.

Research

The artifacts, in the form they were used – readable, not screenshotted. Each starts with the finding it produced. MarketGuard and FinchTrade shared a design system, not a study – the interviews, the testing, and the card sorting below were run for this product. Every table here is transcribed from the working research board.

User personas

What it produced: three buyers with incompatible definitions of “good”. The CEO buys to avoid a fine and never opens the product again. The Product manager evaluates it once, mostly on whether the API can be trusted. The Compliance officer lives in it daily and is the only one who judges it on the work itself. Designing one interface for all three was the central problem of the project.

Persona comparison, from the jobs-to-be-done interviews

CEO or Co-founder Product (CPO, owner, manager) Compliance (CCO, MLRO, AML officer)
Age 30–45 years old 30–45 years old 30–50 years old
Gender Male Male / female Male / female
Education Higher education (economics, finance, IT) Higher technical education Higher legal or financial education
Income High Above average Medium
What functionality is important in a product? Meet the requirements of a regulator; bug-free.
  1. API
  2. UI to double-check API results
  1. Meet regulatory requirements
  2. Automation
  3. Easy to customise and user-friendly
  4. Reporting – the product must be able to cover reporting obligations
What are the goals from interacting with the product? No direct goals. The main goal is to satisfy the company's needs and obligations.
  1. Plug and play; no integration costs, in money or time
  2. Price – ideally no monthly fixed payments
  3. Billing dependent on actual usage
 Get a feel for the product – is it techy (functional but overloaded with features) or flashy (a lot of animation but low on functionality)? Find a tool to cover regulatory requirements:
  1. Can it be automated to flag expired documents, clients due for review, unusual transactions, or transactions that do not fit the client's economic profile?
  2. Can it produce the required reporting, and is it easily customizable to produce reports the regulator asks for?
  3. Does it have an audit trail, to demonstrate to the regulator, auditor, or client when changes were made and by whom?
  4. Can the Compliance officer get a user-friendly overview of each client – risk category, economic profile, documents, funds available, incoming and outgoing transactions?
What motives does the persona have?
  1. The user can do everything themselves, with no ticket to a developer
  2. Minimize the risk of being fined by a regulator if AML controls are weak
  3. Cut compliance department staff costs by providing a handy automation tool
 Avoid building something already available on the market at a lower cost
  1. Have most required solutions in one product – KYC checks, screening, transaction monitoring, reporting, storage
  2. Cover AML and compliance obligations despite limited personnel
What are the pains and fears?
  1. Fear of the business being closed by a regulator
  2. Fear of a large fine
  3. Cost of compliance staff and MLRO salaries, hence the wish to automate 99% of the process
  1. Fear that the product will not meet updated requirements in the near future
  2. How the data is protected, and whether it is compliant
  3. Over-consumption of credits that could stop the service
  4. No test environment
  5. Delayed support
  1. Not being able to cover regulatory obligations
  2. Not being able to monitor KYC and AML transactions properly and on time
  3. Cannot automate fully
  4. Not customizable, and unable to produce necessary reports
  5. Support that is not good or responsive
How often does the persona use the product, and for how long? Never, or only once when selecting a solution
  1. Setup
  2. Initial support for the team
 If the product delivers one-stop solutions, it becomes the Compliance officer's main daily tool – so in that sense, their daily work is covered.

Jobs-to-be-done interviews

What it produced: the requirements list for the MVP. The guide deliberately asks about the working day rather than about the product – what the person does, what breaks, when it last broke – so the answers describe a job to be done and not a feature wish list.

Interview script, in the two blocks it was run in

QuestionWhat it is there for
Show me how you built your daily workflowOpens with observation, not opinion
What tasks do you solve during the day?Maps the job, before any product is mentioned
What applications do you use?Names the incumbent tools and the gaps between them
What limitations or problems do you face in your workflow? How are you trying to solve the problem?Separates the pain from the workaround already in place
When was the last time this problem occurred?Recency test – a problem no one can date is not a problem
Why is this situation terrible?Gets to the consequence: a fine, a review, a lost client
What 3 aspects of your workflow would you like to improve first, and why?Forces ranking instead of a wish list
What task do you solve with this function? Why do you need this result?Ties a requested feature back to a real job
Why do you like this idea?Surfaces the reason behind approval, which is where the requirement hides
What data can be viewed?Draws the boundary of what compliance may legally show
Who else should I talk to?Recruits the next interview from inside the segment

Customer journey maps

What it produced: the order of the website. The map runs find product → analyse details → book demo → demo session → payment → support, and the recommendations row is where it turned into build decisions: navigation organised by persona and use case, the use-case block repeated below the fold, a release-notes page.

Three maps, one per buyer, transcribed from the same board – switch segment above the table

StepActionsTouchpointsExpectations and goalsRecommendations
Find product
  1. Clicks on the link in social media
  2. Clicks on the link in search results
  3. Clicks on the link in chat
  1. LinkedIn
  2. Google
  3. Community research / link in inbox
By the look of the link in the chat, the user should be sure to get to where they need to goCreate an original meta description, title, and og:image for each page
Analysing product details
  1. See how one compliance tool replaces 5
  2. Analysing the list of supported tokens, banks, exchanges, blockchains, and regulated countries
  3. Read customer feedback on the website and LinkedIn
  4. Read the about-the-team block on the website
  5. Analysing the frequency of product updates
  6. Analysing product backlog
  7. Analysing product news
  1. Meet the block with this type of use case on the front page
  2. Meet this type of use case in navigation
  3. Land on the exact page with a link
The user should be able to quickly find the information and product details they are looking for
  1. The list of use cases should be on the first screen of the site
  2. The list of use cases should be duplicated in the navigation
  3. Each page should have an original og:image detailing the case study it is dedicated to
  4. Start a knowledge base describing all the subtleties and mechanisms of the platform
  5. Make a product release page
  6. Make a page with a public backlog
  7. Each use-case page should describe the full range of integrations, blockchains, banks, and regulated countries
  8. Compose an email funnel based on the client's use case – which needs an email collection form on every use-case page
Booking demoBook a demo or sales call
  1. LinkedIn CTA button
  2. Website navigation button, website CTA buttons
  3. Company PDF documents and one-pagers
  1. Easy scheduled sales / demo call
  2. See available call slots on the calendar
  1. After receiving the request, the manager should send a calendar with available slots to the client
  2. The manager should emphasise the quality of technical support on the call
Demo sessionConnect to the meeting via Google Meet, Zoom, etc.Own laptop
  1. Good impression from a demo call
  2. Get answers to any questions that may arise
  3. Possibility to check own scenarios
  1. Managers introducing the product should send a summary to the customer at the end of the call
  2. If the customer has questions, the manager should close them with a detailed answer or a link to the knowledge base
  3. Frequently recurring questions should be collected in a knowledge base
  4. The manager running the demo session should be able to answer non-standard technical questions
PaymentAnalysing pricing plansWebsite navigation buttonTransparent and easy-to-understand price sheet
Contact customer supportClick the customer support button in the user portal
  1. User portal CTA button
  2. User portal chat widget
  3. User portal email link
Responsive and quick support teamThe answer given to the user in chat is duplicated to the user's e-mail

Information architecture

What it produced: a structure a buyer under regulatory pressure can scan – coverage and compliance answers on the surface, product detail one level down.

The site map as built – columns are top-level pages, rows the blocks inside them

MainpageUse cases – Client onboardingUse cases – Transaction monitoringUse cases – Treasury management (coming soon)FAQAbout teamRelease notes pagePricingRequest demo CTA
Demo video of our solutionFeatures: KYC/KYB, automated workflow, custom statuses, wallet verification – the smoothest and quickest way to onboard your clientsFeatures: client–Tx link, KYT, external integrations, case management, reporting – extract transaction history and/or client information for one or more clientsFeatures: unified dashboard, funds manager, automated settlement, supported venuesSupported: countries, blockchains, integrations (banks, exchanges, custodians)Our teamRelease notesChart with prices / discountsContact form
Use cases (user finds a solution they need)Integrations listFeatures listGlossaryWe are hiringRuntime sectionPayment CTACalendly link
See how one tool replaces 5, and which oneProcess overviewAML transaction monitoring – process overviewTravel ruleCrypto events
Show a report on a product pageBlockchain transaction monitoring – process overview
NewsSupported blockchains list
FooterFooterFooterFooterFooterFooterFooterFooter

Usability testing and surveys

What it produced: the fixes that went into the next iteration – and the numbers under the activation result. The most critical user tasks are prototyped and tested with groups of 5–7 participants, run in Maze on Figma prototypes, with participants recruited through LinkedIn.

Tasks given to participants

  • Log in to your account
  • Add a new address on the ETH network 0×71C7656EC7a… to the list of trusted
  • Create a new user with viewing permissions
  • Open a new BTC/USDT selling order in the amount of 100 USDT

Questions asked after the run

  • How intuitive was the process?
  • How easy or difficult was it to navigate around the product?
  • Do you have any comments that you wanted to add during the test?

Maze, Figma and LinkedIn

Findings are synthesised with the product team into a prioritised list of design and architecture improvements. In repeat testing, task completion time decreased by 45% and task completion rate reached 100%. The satisfaction score for the most complex flow – address whitelisting – reached 90%.

Kirill Bush, 2026 ©