Margin-financing platform for Yimeng — products, subscriptions and computed fees

The situation

Yimeng operates a margin-financing platform. An investor puts up capital, the platform supplies leverage at a contractual ratio, and the investor subscribes to a product for a term, pays interest and a management fee, and is redeemed at the end of the term or at maturity. The business needed a public site with products and account pages, a back office to configure products, and a customer-service console.

The risk in this kind of build is not the website. It is the arithmetic and the trail behind it: interest, management fees, redemption amounts and maturity settlement, all of which are contractual, all of which a customer will query, and all of which a business of this kind has to be able to justify to a regulator.

The call we made

Make the calculation the core of the system, and make every figure reproducible.

The easy version stores a status on a subscription — active, redeemed, expired — and lets staff compute fees when needed, or computes a fee once and writes the result into a field. Both fail the same way. When a customer disputes a charge, or when a product’s terms are revised and an existing subscription has to be re-checked, nobody can show how the number was produced.

So fees are derived, not typed. A fee is computed from the subscription’s own inputs — amount, product rate, term, dates, and the redemption events that actually occurred — and stored together with those inputs. Recomputing later gives the same answer, and a disputed charge can be shown line by line. When a product’s terms change, existing subscriptions keep the terms they were sold under, because the terms are captured at subscription time rather than read from the current product record. That single decision is what makes the platform defensible months later.

Subscription and redemption are events on a position, not status overwrites. A position has a history: subscribed on a date for an amount, partly or fully redeemed later, settled at maturity. Overwriting a status destroys exactly the history the settlement calculation needs, and it also destroys the audit trail the business is required to keep.

The customer-service console reads the same data the customer sees. Support staff working from a separate CRM cannot answer “why is my fee this amount” without asking someone else. The console was built on the live business data — the customer’s products, positions and fee breakdown — with communication records and work orders alongside, so a support conversation starts from the figures in dispute.

What we built

• Product listing and configuration: term, leverage terms, rates and availability, managed from the back office.
• Online subscription and payment, with account and holdings views for the customer.
• Redemption and maturity settlement, with the position history retained through both.
• Automatic interest and management-fee calculation, with the inputs stored alongside every result.
• Customer-service console with customer records, positions and work orders over live business data.
• Integration with Yimeng’s securities information capability, so the platform sits inside the existing service rather than beside it.
• Audit trail on product changes and account operations.

Result

Subscriptions and redemptions run as a closed loop, from product configuration through to settlement, and the fee arithmetic is done by the system rather than by a person with a spreadsheet. Support conversations start from the same numbers the customer is looking at, which shortens them considerably.

The regulatory point is the one the client cared about most and the one least visible in a demonstration: every charge has a recorded derivation, and every product change is logged. That is what allows the business to answer a query that arrives months after the fact without reconstructing it from emails.

For a financial product, the website is the easy part. The question worth asking before the first screen is designed is which numbers a customer or a regulator will ask you to justify, and whether the system will be in a position to answer.

Technology

Stack	Vue 3 · Spring Boot · MySQL · Redis
Delivery model	Custom web platform
Client	Yimeng Software
Status	Delivered

What we cannot show

Customer accounts, positions, fee statements and payment records are not published. The views shown are from the delivered system.

Similar problem?

If this looks like something you are dealing with — a legacy system that must keep running, a workflow no product covers, an integration nobody wants to touch — send a short description. We will tell you honestly whether we are the right team, and what the first two weeks would look like.

Ask about this project