Product Journey - Case Study

Designing Multi-Source Money Flow: From Cashback to Core System

MoMo EWallet & Finance Services

• English
• Vietnamese

• In 2020, after the Covid pandemic, I formally joined MoMo – one of the pioneering companies in fintech industry, focus on e-wallets and digital financial solutions in Vietnam. The project I was responsible for was the Loyalty Program. Interestingly, when I took over the project, its concept was fundamentally built on an Earn & Burn model with a cashback-centric approach. However, the business model had modified for 3 times before, these shifts undirectly had a significant impact on the product's future technical architecture, but this also gave me the opportunity to directly participate in designing and building its monetary processing system later on.

  In this story, I will provide you with some insights into the process of building this system at MoMo, as well as a similar variation combining Fiat and Blockchain on a smaller scale.

  From Core Banking to Core MoMo

  Before joining MoMo, the concept of "Core Banking" was entirely new to me. Of course, MoMo also had a similar system - but what's fascinating is that Core MoMo was fully developed in-house rather than relying on 3rd-party solutions. This allowed me to expand my understanding of its unique financial tech-system. So, during my first week at MoMo, alongside reviewing the PRD and analyzing the product's current state, I realized that learning about Core MoMo was my top priority. Gaining a deep understanding of how this system operates not only helped me grasp the technical foundation but also gave me a critical viewpoints for manage my works or my taks later on.

  
  
  

  Fundamentally, Core MoMo primarily focuses on 3 key missions:

  • Ensuring the balance and transparency of money flow: This means its primary focus is on handling financial transactions with high performance. It ensures that every transaction is recorded accurately in real time, preventing any discrepancies and denying imbalances within the system.
  • Prioritizing system security: Unlike other back-end systems that often prioritize data retrieval, Core MoMo emphasizes its security. Critical APIs, such as account balance checks, are still provided to support essential features, but the system remains heavily guarded.
  • Compliance with regulations and audit practices:Similar to Core Banking, Core MoMo adheres to financial standards and regulations issued by government agencies, such as the State Bank of Vietnam. This includes fully recording transactions and generating reports to meet audit requirements.

  Therefore, for day-to-day transaction operations, both Core Banking and Core MoMo have their corresponding back-end systems to jointly handle financial processes. However, beside of checking the amount and status of transactions, we often focus heavily on the error-codes. These codes closely reflect the synchronization between the two systems and their impact on subsequent money flow processing.

  Loyalty Program - Cashback Model

  The business model of the Loyalty project revolves around cashback model - meaning that when you complete a successful transaction, a portion of the money is refunded to your account and can be used for other transactions. Additionally, the more frequently you spend, the greater the benefits you receive, including higher cashback rates or buying discounted offers for transactions.

  The key to evaluating the success of a Loyalty Program, as you might guess - lies in its ability to uplift the volume or frequency of user transactions. However, from the perspective of a Product Manager, I believe it holds even greater business potential. If our product is well-designed, it can evolve into a new Solution as a Service (SaaS), unlocking new opportunities for the project.

  
  
  

  When I took over the project, Loyalty was in its Phase 2 of Trial process, with 80,000 white-listed users invited to participate. At this stage, the project's structure was set up as follows:

  1. We utilized a wallet from another project to directly store cashback money: I often called it Wallet Pocket to avoid confusion with terms like Sub-account or Wallet Segmentation. The reasoning was straightforward: cashback is real money, and when handling monetary transactions, you must strictly comply with legal regulations, ensure transparency, and effectively manage those risks. Meeting all these requirements from a technical standpoint is a challenge, especially since our project was still in the trial phase. Therefore, using an already-established technical platform from another project was the most cost-effective solution, even though it can cause some limitations in our project & product management.
  2. The tier-based ranking system and cashback benefits: Specifically, users earn ranking points (e.g. Silver, Gold) when completing transactions, with the points calculated based on the amount and type of transactions. These points are valid for 30 days, also the total ranking points are determined based on most recent 30 days.
  3. 80% of all B2C transactions can have cashback transactions: But those transactions will have their limited cashback amounts based on GMV, number of transactions per group and based on tier in the ranking system. Technically, these cashback transactions are processed directly within the Core MoMo system.
  
  
  
  
  

  At first glance, everything seems quite promising from a business perspective, doesn't it? However, there was a significant technical issue - the 30D expiration mechanism in its dynamic ranking system. Setting a 30-day expiration for each transaction is not uncommon in practice, but this mechanism is far less prevalent when applied to applications or services with high transaction volumes, such as those in the financial or FMCG sectors.

  
  

  Issue 1: Limitations and Data Processing Risks When Using Core MoMo

  Cashback transactions were processed directly within the same transaction on Core MoMo. This raised concerns, as any issues related to the Loyalty program could potentially impact Core MoMo. The program's points or cashback capset and expiration mechanisms were particularly complex and problematic, further amplifying these risks.

  
  

  Let's take a look at this from a system perspective. If you make a transaction at time T1, your reward points will remain valid until T1+30 before they expire. However, imagine having hundreds of transactions at different times (Tn+30), and scaling that up to 20 million users like you - the daily volume of expiration processing would become enormous. This workload would explode quickly, especially from the 2nd month onward, when the number of expiring points begins to pile up. While this is not an unsolvable problem, it does significantly increase the risk of highly-rising operational costs.

  
  
  
  
  

  At this point, a more concerned question arises: What happens if a transaction is refunded? The answer is far from straightforward.

  If someone were to ask me about the most critical aspects of financial transaction processing, aside from audit and reconciliation, I would say refunds are also among the most challenging. For users, a refund seems quite simple - you just get back what you paid for. But from the perspective of the solver, it's much more complex, as there are numerous intricate factors that need to be carefully addressed, such as:

  • Where did your money come from? What was the source of this fund?
  • Which pocket did you use to pay for this transaction previously?
  • Did you use any coupons for this transaction? If yes, what are the terms of use for that coupon?
  • Was your transaction part of any promotional program?
  • Was there a partner involved in covering part of this promotional transaction?
  • What were the transaction fees, and where did those fees come from?

  And countless other questions arise with every transaction you're attempting to refund. Naturally, it is our responsibility to address them thoroughly. During this period, the idea of developing a standalone "Core Loyalty" system began to take shape in my mind. However, several critical factors were still missing before making a final decision.

  Core Loyalty: Where Innovation Begins

  As previously mentioned, the Loyalty Program utilizes a pocket from other project to store cashback funds for users. However, after reviewing and assessing the state of the project, we uncovered another issue:

  
  

  Issue 2: Extremely low cashback cashout rate or reuse rate.

  Even after conducting user surveys, we found that trial users were often unaware of the cashback amount credited to their pocket. This presents a significant concern to our team.

  
  

  At this point, in addition to upgrading its UX and improving CX, we also began re-evaluating cost optimization and do the risk mitigation from a project management perspective. After aligning with the development team, we decided to propose a bold solution: Let's build Core Loyalty!

  For technically complex architectures like Core Loyalty, working with stakeholders and key decision-makers requires careful consideration of how to communicate ideas to ensure alignment without obstacles. Instead of solely relying on PRDs or UML diagrams - which can feel hard to catch up - I typically simplify them and convert to critical business flows, making it easier for the team to grasp the concepts. So the process of explaining the proposal to leadership and proceeding with implementation went smoothly at that time. There were several reasons why building Core Loyalty was a reasonable decision at this point:

  1. Operational Stability & Scalability: At that time, we were planning to expand the testing user base to 1.2 million users. Continuing to rely on Core MoMo for project operations carried significant risks, potentially disrupting MoMo's core functions. Separating and building a dedicated Core Loyalty system was essential to ensure both stability and scalability for the loyalty program. This separation safeguarded MoMo's primary operations while allowing the loyalty program to grow independently.
  2. Centralized Operations: Core Loyalty allowed us to centralize development, management and operations of the Loyalty program, eliminating its dependency on systems from other projects. With both governance and technical control consolidated into a standalone platform, our project team gained enhanced oversight. This shift also facilitated the overall technical growth of our dev team, enabling them to take full ownership of the loyalty system.
  3. New Wallet Pockets: Establishing separate pockets provides more sustainable control over program operations. With Core Loyalty, cashback is stored as points in this wallet, and users are required to take an additional step to cash out those amount to their primary pocket (MoMo Core). This approach not only helps reduce the waste caused by users' "dormant" funds but also creates an opportunity for us to analyze and closely observe user behavior, how they use or spend these money.
  4. Technical Feasibility: From a technical standpoint, our dev team already possessed the necessary expertise to develop Core Loyalty, giving us a significant advantage. Furthermore, the logic and architecture of the product were clearly defined, minimizing development time. Building Core Loyalty could be done in parallel with revamping the UI, adding new features to improve both UX and CX for its program.

  Redefining Systems with a New Refund Mechanism

  Core	Agent Name	Description
  Loyalty	loyalty_cb.agent_cb.convert	Used to convert cashback amounts to user's Cashback Wallet (Loyalty Wallet).
  Loyalty	core_loyalty_cashbackconvert	Used to process transfer requests from the Cashback Wallet → MoMo Wallet.
  Loyalty	loyalty_cb.agent_cb.loyalty_benefit.2	Used to determine Silver rank and the corresponding benefits for the user.
  Loyalty	kgs_gmc_loyalty_coreloyalty_bac	Used to calculate cashback amounts for Silver tier user-groups.
  MoMo	loyalty_cashback_convert	Used to process money transfer command to the correspoding pocket.
  ...	...	...

  I often describe our work is to build "a city within a city," much like Thu Duc City within Ho Chi Minh City. This comparison is quite accurate, as Core Loyalty will operate in parallel but remain directly connected to Core MoMo, rather than being entirely separate.

  After consolidating all the tasks that need to be carried out, I identified three main objectives in designing Core Loyalty:

  Building the money processing flow between Core MoMo & Core Loyalty: This is the most critical task. In MoMo, we often use the term "agent" to describe ledger accounts responsible for storing and managing cash flows within the Core system. However, Core Loyalty is designed to focus on calculating points, ranking, and cashback. So the agents in Core Loyalty primarily known as calculation modules. In contrast, the agents responsible for handling true money transactions are located in Core MoMo. For example, a cashout agent in Core Loyalty corresponds to a cashin agent in Core MoMo. Fundamentally, ensuring the rule "debit = credit" between two Core systems is an inviolable principle during the design process.

  
  
  

  Establishing New Refund Processing System: When we were building Core Loyalty, one of the major concerns was handling refunds for legacy transactions. The technical architecture between Core MoMo and Core Loyalty had been clearly revamped, but this move made their relationships with the large volume of old transactions became more complex. Honestly, at that time, I couldn't find a good solution because there was one approach I had never considered - the existence of two refund systems at the same time, but just for short term. While this option was quite costly in terms of technical resources, it was the most reasonable choice to ensure our system operated smoothly. This solution was suggested to us by the senior technical director.

  Theoretically, any transactions can be refunded for up to 3-months period, and for each SOF (Source of Fund), the refund process must comply with specific regulations mandated by the law. This is particularly challenging for SOF like credit cards or pay-later wallet, which have different mechanisms. Below is a typical example of our refund use cases:

  Case C: User makes a transaction using Credit Card for 100,000đ, receives a cashback of 10,000đ, and proceeds with a refund of 70,000đ based on the original transaction amount.

  Step 1: The Back-End service receives the refund request from the user.

  Step 2: Based on the information provided by Core Loyalty, Core MoMo performs the following calculations:

  • → Cashback amount to be reclaimed = 7,000đ, which needs to be transferred to loyalty_cashbackconvert.
  • → Refund amount after deduction = 63,000đ, which needs to be transferred back to the Credit Card.
  • → BE Bank receives the corresponding amount information and processes the refund via Core Cybersource.

  Step 3: BE Bank confirms the refund is successful and sends the result back to Core MoMo to finalize the process.

  Step 4: Process the information for notifications, transaction details, and transaction history. Refund is completed.

  
  

  Setting up Blacklist Mechanism: In monetary systems, handling blacklists is an essential component. When both Core MoMo and Core Loyalty are operational, if a user is blacklisted in Core MoMo, we need to synchronize and take appropriate action in Core Loyalty, and vice versa. However, there are exceptions, such as cases where a user is only blacklisted in one system (due to personal factors or business requirements) or is restricted/blocked solely within the scope of Loyalty or for a specific time. Essentially, our handling mechanism relies on an event-and-value-based system to ensure overall consistency during multi-team execution.

  
  
  

  In summary, completing the above tasks marked the completion of building the Core Loyalty system. However, before the system officially went on-air, we thoroughly prepared a handover and upgrade plan to ensure a smooth deployment process.

  Alongside improvements to the Loyalty technical system, we also implemented major updates to its UI and features, enhancing the overall user experience. Based on prior in-depth analyses, these changes ensured a consistent experience across the entire Loyalty program in MoMo, not just from a technical perspective. However, this article will focus solely on the monetary system aspect that I was directly involved in contributing.

  
  
  
  
  

  Start as a Concept, Built as a System, Delivered as a Solution

  The biggest difference of Core Loyalty lies in the fact that it does not directly handle actual monetary transactions. This means many financial technical barriers have been eliminated, creating room for us to explore additional potentials. One of the most notable features is the ability to establish multi-pocket.

  Initially, Core Loyalty was designed with just 2 Pockets: one for storing rank points and another for cashback points (with a 1:1 conversion rate with real money). However, the system's dynamic architecture allows us to easily create new wallet pockets and customize the calculations within them to adapt to real-world business scenarios. This opens up the possibility for Core Loyalty to be evolved and become a comprehensive Loyalty platform for enterprise customers.

  Separate Pockets can be established and operated using dedicated agents. From a business perspective, this means - in addition to implementing the Loyalty program for MoMo itself, MoMo's partners can also customize and run their own independent promotions or joint campaigns on this platform. Below is an example of how we implemented a cashback model using multi-pocket functionality on Core Loyalty during the initial phase.

  A = Loyalty Pocket. This pocket operates according to the existing cashback program. It is configured as follows:

  • Receive a maximum of 10.000đ per transaction depended on different service groups (capset & limit based on service group tiers).
  • Receive a maximum of 25.000đ per day and a limit of 10 transactions per month.

  B = CGV Pocket. This pocket is specifically created for a campaign offering cashback of 10.000đ for users purchasing CGV movie tickets for the first time. It is configured as follows:

  • Only records transactions originating from CGV ticket purchases (based on service IDs).
  • Always provides 10.000đ cashback per transaction for transactions valued above 80.000đ.
  • Maximum of 2 transactions per user during the campaign period, from May 15 to May 30.
  • Agent is set with a budget of 100 million VNĐ, equivalent to 10.000 transactions eligible for the campaign.

  C = Baemin Pocket. This pocket is created for a campaign offering double cashback for Milk Tea purchases, applied to the user's current rank. It is configured as follows:

  • Only applies to users with a rank of Gold or higher.
  • Users receive double the cashback value for any Baemin transactions exceeding 200.000đ.
  • Campaign duration is from May 15 to May 22 (1 week).
  • Agent is set with a budget of 200 million VNĐ, and the program runs until the budget cap is reached.

  Although I didn't start the Loyalty project from its beginning or go along with it in later expansion, my time working at MoMo provided me a new insights into how fintech systems operate. Later, I applied these experiences to build up a payment system that have connections between fiat, blockchain and 3rd party services on a smaller scale.

  
  
  

  Key Takeaways

  The entire process of building and optimizing Core Loyalty took us about 3 months. While not an excessively long timeframe, it still provided us with valuable lessons along the way.

  1. Scalability Matters: Payment systems must be designed with scalability in mind from the very beginning. A lack of foresight can quickly become a bottleneck when the user-base grows. Later, when working with Tencent on another project, I observed that they also adopted that system design approach, ensuring that each feature/modular could handle up to 1 billion transactions per day. This may seem like an "over-estimation" at first, but in reality, it’s a crucial factor to anticipate early on - especially when a project suddenly grows. At that point, refactoring an architecture would be harder.
  2. Idempotency & Rollback Are Must-Have: In this article, there's an important mechanism that I haven’t mentioned in the Core system is rollback. This plays a crucial role in financial transactions, ensuring that each transaction is executed only once and that the system can revert to a consistent state in case of errors or interruptions. Additionally, rollback significantly contributes to optimizing the processing flow of the Core system.
  3. Business & Tech Alignment is The Key: A well-designed system must not only be technically robust but also aligned with business strategy. Choosing the right system architecture requires careful consideration of operational efficiency, cost, and customer experience. Actually, the Core Loyalty system I worked on had high operational costs, which may became a barrier to the project's success. For a product perspective, I think this is a critical factor to evaluate before starting, to ensure that the system is not only technically strong but also sustainable from a business standpoint.

  Summary

  This article focuses on practical experience and solutions that my project team did implemented, without getting into too much detail about the Core Banking system. From the perspective of a Product Manager, this allows me to approach the topic from both the product experience and system strategies thought. I hope this article can provide valuable insights, especially for those looking to implement similar solutions.

  

  Thanks for reading my little story.
• 
  

  Vào năm 2020, sau khoảng thời gian đại dịch Covid, tôi chính thức gia nhập MoMo - một trong những công ty tiên phong trong lĩnh vực Ví điện tử & giải pháp tài chính số tại Việt Nam. Dự án tôi chịu trách nhiệm chính là Loyalty Program, điều khá thú vị là khi tôi tiếp nhận dự án, dù về cơ bản concept của nó được xây dựng trên mô hình Earn & Burn với cashback model làm trọng tâm, nhưng mô hình kinh doanh đã trải qua 3 lần thay đổi. Những thay đổi này vô tình gây ảnh hưởng lớn đến kiến trúc kỹ thuật của sản phẩm, nhưng nhờ vậy tôi mới có được cơ hội trực tiếp tham gia vào việc thiết kế và xây dựng hệ thống xử lý tiền tệ sau này của dự án.

  Trong câu chuyện này, tôi sẽ cung cấp cho bạn một số góc nhìn về quá trình tôi xây dựng hệ thống này ở MoMo, cũng như biến thể tương tự khi kết hợp giữa Fiat & Blockchain ở quy mô nhỏ hơn.

  From Core Banking to Core MoMo

  Trước khi gia nhập MoMo, khái niệm “Core Banking” đối với tôi là thứ gì đó hoàn toàn mới mẻ, đương nhiên là ở MoMo cũng tồn tại một hệ thống tương tự - điều thú vị là Core MoMo được công ty tự phát triển hoàn toàn, thay vì sử dụng giải pháp từ đối tác thứ ba, điều này giúp tôi có thể mở rộng kiến thức về hệ thống tài chính nội bộ độc đáo của nó. Vì thế trong tuần đầu tiên tại MoMo, bên cạnh việc đọc lại PRD, phân tích tình trạng sản phẩm, tôi nhận ra rằng việc tìm hiểu về Core MoMo là ưu tiên hàng đầu. Hiểu rõ cách hệ thống này hoạt động không chỉ giúp tôi nắm bắt được nền tảng kỹ thuật, mà còn tạo tiền đề quan trọng cho việc xử lý công việc sau này.

  
  
  

  Về cơ bản, Core MoMo chủ yếu tập trung vào 3 nhiệm vụ tối thượng của nó:

  • Đảm bảo sự cân bằng luồng tiền và tính minh bạch của dòng tiền, nghĩa là tập trung hoàn toàn vào xử lý các giao dịch tài chính ở hiệu suất cao. Đảm bảo mọi giao dịch đều được ghi nhận chính xác theo thời gian thực, không gây ra chênh lệch hay mất cân bằng trong hệ thống.
  • Ưu tiên bảo mật tuyệt đối, thay vì phục vụ mục đích truy xuất dữ liệu như các hệ thống Back-End thông thường. Một số API quan trọng, ví dụ như dùng để kiểm tra số dư (balance), vẫn được cung cấp để hỗ trợ các tính năng cần thiết.
  • Tuân thủ quy định và nghiệp vụ kiểm toán, giống như Core Banking - Core MoMo cũng đáp ứng các tiêu chuẩn và quy định tài chính được ban hành, như yêu cầu của Ngân hàng Nhà nước chẳng hạn. Bao gồm cả việc ghi nhận đầy đủ các giao dịch và báo cáo để phục vụ kiểm toán.

  Vì thế đối với các hoạt động giao dịch thường ngày, Core Banking & Core MoMo cũng luôn có hệ thống Backend vệ tinh để cùng nhau hỗ trợ thực hiện các nghiệp vụ tài chính. Tuy nhiên khi 2 hệ thống tương tác với nhau, ngoài việc kiểm tra khối lượng và tình trạng của các giao dịch, thường thì chúng tôi sẽ quan tâm đến các mã lỗi khá nhiều, vì chúng phản ánh mật thiết sự đồng bộ từ 2 hệ thống và những ảnh hưởng đến luồng xử lý tiền sau đó.

  Loyalty Program - Cashback Model

  Mô hình kinh doanh của dự án Loyalty xoay quanh cashback – tức là khi bạn thực hiện giao dịch thành công, một phần tiền sẽ được hoàn trả vào tài khoản của bạn và có thể sử dụng cho các giao dịch khác. Ngoài ra, mật độ chi tiêu càng cao thì người dùng càng nhận được nhiều quyền lợi hơn, bao gồm cả mức cashback cao hơn lẫn chiết khấu ưu đãi cho các giao dịch.

  Chìa khóa để đánh giá sự thành công của Loyalty Program, như bạn có thể đoán, chính là việc chương trình có thể thúc đẩy (uplift) khối lượng hoặc tần suất giao dịch của người dùng. Tuy nhiên, dưới góc nhìn của một người làm Product, tôi lại cho rằng nó còn có tiềm năng kinh doanh lớn hơn nữa - nếu sản phẩm được thiết kế đủ tốt, nó hoàn toàn có thể phát triển thành một giải pháp dịch vụ (Solution as a Service), mở ra những cơ hội mới cho dự án.

  
  
  

  Thời điểm tôi tiếp nhận dự án, Loyalty đang ở giai đoạn thử nghiệm phase 2 với 80.000 người dùng được mời trải nghiệm. Lúc này về mặt cấu trúc, dự án đang được thiết lập như sau:

  1. Chúng tôi sử dụng một ngăn ví từ dự án khác để lưu trữ trực tiếp tiền cashback. Tôi thường gọi nó là Wallet Pocket nhằm tránh nhầm lẫn với các khái niệm như Sub-account hay Wallet Segmentation. Lý do rất đơn giản: cashback là tiền thật, và khi xử lý tiền tệ, bạn cần tuân thủ nghiêm ngặt các quy định pháp lý, đảm bảo yếu tố minh bạch, cũng như quản lý rủi ro hiệu quả. Việc đáp ứng tất cả các yêu cầu này về mặt kỹ thuật là một thách thức không nhỏ, đặc biệt khi dự án của chúng tôi chỉ đang trong giai đoạn thử nghiệm. Do đó, sử dụng nền tảng kỹ thuật đã được thiết lập từ một dự án khác là giải pháp tối ưu về mặt chi phí tổng thể, dù nó có thể gây ra một số hạn chế nhất định trong khâu quản trị.
  2. Cơ chế ranking phân hạng với quyền lợi cashback tương ứng. Cụ thể, người dùng sẽ nhận được điểm dùng để phân loại bậc hạng (Bạc, Vàng,..) thông qua các giao dịch, số điểm này được tính dựa trên loại hình và khối lượng giao dịch tương ứng. Điểm trên mỗi giao dịch sẽ có hiệu lực trong vòng 30 ngày, đồng thời tổng điểm dùng để xếp hạng cũng được tính dựa trên dữ liệu của 30 ngày gần nhất.
  3. Các nhóm giao dịch phát sinh cashback chiếm khoảng 80% các loại giao dịch của MoMo nhưng có giới hạn về số tiền cashback, chủ yếu là dựa trên GMV lẫn số lượng giao dịch quy định trong từng cụm nhóm cũng như tỉ lệ cashback tính theo bậc hạng trong hệ thống ranking. Về mặt kỹ thuật, các giao dịch cashback này được xử lý trực tiếp trên hệ thống Core MoMo.
  
  
  
  
  

  Nhìn thoạt qua, mọi thứ có vẻ khá hay ho về mặt kinh doanh, đúng không? Tuy nhiên, lại tồn tại một vấn đề khá lớn về mặt kỹ thuật – đó chính là cơ chế hết hạn điểm (expiration) trong hệ thống xếp hạng động 30 ngày mà chương trình đã thiết lập. Việc đặt expiration 30D theo từng giao dịch không phải là điều hiếm gặp trong thực tế, tuy nhiên, cơ chế này ít phổ biến hơn khi áp dụng vào các ứng dụng hoặc dịch vụ có khối lượng giao dịch lớn như lĩnh vực tài chính hoặc FMCG.

  
  

  Vấn đề 1: Giới hạn và rủi ro xử lý dữ liệu khi dùng Core MoMo

  Tiền cashback được xử lý trong chính giao dịch đó ở Core MoMo, điều này đáng lo ngại nếu các yếu tố liên quan đến Loyalty gây vấn đề ảnh hưởng đến MoMo do những cơ chế quản lý capset và expiration của chương trình khá phiền phức.

  
  

  Hãy thử nhìn dưới góc độ hệ thống một chút. Nếu bạn thực hiện một giao dịch tại thời điểm T1, điểm thưởng của bạn sẽ tồn tại đến T1+30 trước khi hết hạn. Tuy nhiên, giả sử bạn có hàng trăm giao dịch tại các thời điểm khác nhau (Tn+30), và có đến 20 triệu người dùng giống bạn, thì khối lượng xử lý các expiration mỗi ngày sẽ trở nên khổng lồ. Khối lượng này còn tăng dần theo cấp số nhân, đặc biệt từ tháng thứ 2 trở đi khi số lượng điểm sắp hết hạn bắt đầu chồng chất. Mặc dù vậy, đây không phải là một vấn đề không thể giải quyết, ngoại trừ rủi ro gia tăng đáng kể về chi phí vận hành.

  
  
  
  
  

  Lúc này, một câu hỏi thú vị hơn xuất hiện: Điều gì sẽ xảy ra nếu bạn tiến hành refund giao dịch? Câu trả lời không hề đơn giản.

  Nếu có ai hỏi tôi về yếu tố quan trọng trong việc xử lý giao dịch tài chính, ngoài kiểm toán (audit) và đối soát (reconciliation), tôi sẽ nói rằng refund (hoàn trả) là một trong những khía cạnh thách thức nhất. Đối với người dùng, refund có vẻ rất đơn giản – bạn chỉ nhận lại những gì đã chi trả. Nhưng từ góc độ của người xử lý, nó lại phức tạp hơn nhiều bởi có hàng loạt yếu tố cần phải xem xét và giải quyết một cách cẩn trọng, chẳng hạn:

  • Tiền của bạn đến từ đâu, xuất phát từ nguồn nào?
  • Bạn dùng tiền từ ngăn ví nào để chi trả cho giao dịch này trước đây?
  • Bạn có sử dụng coupon nào hay không? Nếu có thì coupon đó quy định sử dụng thế nào?
  • Giao dịch của bạn có đến từ chương trình khuyến mãi nào không?
  • Liệu có đối tác khuyến mãi nào chi trả trong giao dịch này hay không?
  • Phí giao dịch của bạn là bao nhiêu và phí này xuất phát từ đâu?

  Và còn rất nhiều câu hỏi khác, tất cả những câu hỏi này sẽ phát sinh trong mỗi giao dịch mà bạn đang tiến hành refund. Đương nhiên, nhiệm vụ của chúng tôi là phải xử lý chúng một cách triệt để. Chính vào thời điểm này, ý tưởng về việc xây dựng một hệ thống “Core Loyalty” riêng biệt bắt đầu nhen nhóm trong đầu tôi. Tuy nhiên, vẫn còn thiếu nhiều yếu tố quan trọng để đưa ra quyết định cuối cùng.

  Core Loyalty: Where Innovation Begins

  Như đã đề cập, Loyalty Program đang sử dụng 1 pocket lưu trữ tiền khác để hứng tiền cashback của người dùng, sau khi thống kê và đánh giá tình trạng của dự án, chúng tôi phát hiện có một vấn đề:

  
  

  Vấn đề 2: Tỷ lệ cashout hoặc tái sử dụng tiền cashback thời điểm đó cực kỳ thấp.

  Thậm chí chúng tôi đã tiến hành khảo sát thì người dùng thử nghiệm còn không biết lượng tiền cashback đã về ngăn ví đó của họ. Đây là vấn đề đáng quan tâm dưới góc nhìn quản trị dự án.

  
  

  Lúc này ngoài việc cần nâng cấp UX và cải thiện CX, chúng tôi cũng bắt đầu đánh giá lại việc tối ưu chi phí và giảm thiểu rủi ro dưới góc độ quản trị dự án. Sau khi thống nhất với anh em dev, chúng tôi quyết định đưa ra một đề xuất: chúng ta hãy build Core Loyalty đi!

  Với những kiến trúc kỹ thuật phức tạp như Core Loyalty, khi làm việc với các stakeholder hay những người ra quyết định quan trọng, tôi cần cân nhắc kỹ cách truyền đạt ý tưởng để đảm bảo sự đồng thuận mà không có vướng mắc. Thay vì chỉ dựa vào những PRD hay UML diagrams vốn khá khô khan, tôi thường đơn giản hóa các luồng nghiệp vụ quan trọng để giúp cả team dễ dàng nắm bắt. Nhờ cách tiếp cận này, việc giải trình và tiến hành triển khai đã diễn ra suôn sẻ vào thời điểm đó. Có nhiều lý do khiến việc xây dựng Core Loyalty trở nên hợp lý:

  1. Vận hành ổn định & Khả năng mở rộng: Tại thời điểm đó, chúng tôi đang lên kế hoạch mở rộng tệp thử nghiệm lên 1.2 triệu user. Việc tiếp tục sử dụng Core MoMo để vận hành dự án tiềm ẩn nhiều rủi ro, có thể gây ảnh hưởng trực tiếp đến hoạt động cốt lõi của MoMo. Vì vậy, việc tách riêng và xây dựng một Core Loyalty độc lập là điều cần thiết để đảm bảo sự ổn định và khả năng mở rộng của dự án.
  2. Tập trung hóa vận hành: Core Loyalty giúp quản lý và vận hành chương trình Loyalty một cách hiệu quả hơn khi không còn phải "ký sinh" vào các hệ thống từ dự án khác. Việc tập trung cả khía cạnh quản trị lẫn kỹ thuật vào một nền tảng riêng biệt cho phép đội ngũ dự án kiểm soát tốt hơn, bao gồm việc thúc đẩy sự phát triển kỹ thuật tổng thể của đội ngũ phát triển (dev team) chúng tôi.
  3. Ngăn ví mới hoàn toàn: Việc thiết lập một ngăn ví riêng biệt mang lại khả năng kiểm soát bền vững hơn trong vận hành business. Với Core Loyalty, tiền cashback được lưu trữ dưới dạng điểm trong ngăn ví này, và người dùng cần thực hiện thêm một bước nữa để cashout về ngăn ví chính (VD: Ngăn Ví MoMo). Cách tiếp cận này không chỉ giúp giảm thiểu tình trạng lãng phí do lượng tiền "nằm yên" của người dùng, mà còn tạo điều kiện thuận lợi để chúng tôi phân tích và quan sát kỹ lưỡng hơn về hành vi người dùng, cũng như cách họ tận dụng các khoản tích lũy này.
  4. Khả năng thực thi: Đội ngũ dev đã sở hữu năng lực kỹ thuật cần thiết để xây dựng Core Loyalty, điều này mang lại lợi thế đáng kể cho chúng tôi. Bên cạnh đó, logic và kiến trúc sản phẩm cũng đã được định hình rõ ràng, giúp giảm thiểu đáng kể thời gian cần thiết để triển khai. Việc xây dựng Core Loyalty có thể được thực hiện song song với quá trình làm mới UI lẫn bổ sung tính năng mới nhằm cải thiện UX và CX của chương trình.

  Redefining Systems with a New Refund Mechanism

  Core	Agent Name	Description
  Loyalty	loyalty_cb.agent_cb.convert	Dùng để chuyển số tiền cashback nhận được về Túi Hoàn Tiền (Ví Loyalty) của user
  Loyalty	core_loyalty_cashbackconvert	Dùng để thực hiện request lệnh chuyển tiền từ Túi Hoàn Tiền → Ví MoMo của user
  Loyalty	loyalty_cb.agent_cb.loyalty_benefit.2	Dùng để xác định hạng Bạc và gói ưu đãi tương ứng của user
  Loyalty	kgs_gmc_loyalty_coreloyalty_bac	Dùng để xác định số tiền cashback cho các nhóm user hạng Bạc
  MoMo	loyalty_cashback_convert	Dùng để thực hiện lệnh chuyển tiền về ngăn Ví tương ứng
  ...	...	...

  Tôi thường ví von rằng chúng tôi đang xây dựng một "thành phố bên trong thành phố," giống như TP. Thủ Đức nằm trong TP. Hồ Chí Minh vậy. Sự so sánh này khá chính xác, bởi Core Loyalty sẽ hoạt động độc lập song song nhưng vẫn kết nối trực tiếp với Core MoMo, chứ không hoàn toàn tách biệt. Sau khi tổng hợp lại toàn bộ công việc cần thực hiện, chúng tôi bắt tay vào việc dựng Core Loyalty.

  Xây dựng luồng vận hành tiền giữa Core MoMo & Core Loyalty: Đây là nhiệm vụ quan trọng nhất. Trong MoMo, chúng tôi thường sử dụng thuật ngữ “agent” để mô tả các tài khoản ledger chịu trách nhiệm lưu trữ và xử lý dòng tiền trong hệ thống Core. Tuy nhiên, Core Loyalty được thiết kế để tập trung vào việc tính toán điểm, hạng và tiền cashback, vì vậy thực chất các agent ở Core Loyalty chủ yếu đóng vai trò như các module tính toán, ngược lại, các agent thực hiện việc xử lý tiền sẽ được đặt ở Core MoMo. Ví dụ, một agent cashout ở Core Loyalty sẽ tương ứng với một agent cashin ở Core MoMo. Về cơ bản, việc cân bằng debit = credit giữa hai hệ thống Core là nguyên tắc bất di bất dịch trong quá trình thiết kế.

  
  
  

  Thiết lập hệ thống xử lý Refund: Khi chúng tôi xây dựng Core Loyalty, một trong những mối bận tâm lớn là việc xử lý refund cho các giao dịch cũ. Kiến trúc kỹ thuật giữa Core MoMo và Core Loyalty đã được phân tách rõ ràng, nhưng điều này lại khiến việc tương thích với khối lượng lớn giao dịch cũ trở nên phức tạp hơn. Thú thực, vào thời điểm đó, tôi đã không tìm ra lời giải, bởi vì có một phương án tôi chưa từng nghĩ đến - đó chính là tồn tại 2 hệ thống Refund song song cùng một lúc trong ngắn hạn, cái này khá tốn kém về chi phí kỹ thuật nhưng lại là lựa chọn hợp lý nhất để đảm bảo hệ thống vận hành ổn định. Đây là giải pháp đã được giám đốc kỹ thuật cấp cao gợi ý cho chúng tôi.

  Về mặt lý thuyết, các giao dịch có thể được refund lên đến 3 tháng, và với mỗi SOF (Source of Fund), quá trình refund phải tuân thủ những quy định riêng theo từng luật định bắt buộc. Điều này đặc biệt thách thức với các nguồn tiền như thẻ tín dụng (credit card) hoặc ví trả sau (pay later) vốn có các cơ chế khác biệt. Dưới đây là một ví dụ điển hình về use case refund:

  Trường hợp C: User thực hiện giao dịch bằng Thẻ Quốc Tế (Credit Card) với giá trị 100.000đ, được cashback 10.000đ và tiến hành refund cho 70.000đ theo giá trị giao dịch gốc

  B1. Back-End service tiếp nhận yêu cầu refund từ user

  B2. Dựa trên thông tin Core Loyalty đã gửi qua, Core MoMo tính toán

  • → Số tiền cashback cần thu hồi = 7.000đ cần chuyển về loyalty_cashbackconvert
  • → Số tiền refund đã cấn trừ = 63.000đ cần chuyển về Thẻ Quốc Tế
  • → BE Bank tiếp nhận thông tin amount tương ứng và xử lý refund với Core Cybersource

  B3. BE Bank xác nhận refund thành công, back thông tin trở lại Core MoMo để finalize kết quả cuối cùng.

  B4. Xử lý thông tin cho notification, chi tiết giao dịch và lịch sử giao dịch. Hoàn thành refund.

  
  

  Thiết lập Blacklist: Trong các hệ thống tiền tệ, xử lý blacklist là một phần không thể thiếu. Khi Core MoMo và Core Loyalty cùng hoạt động, nếu một user bị blacklist ở Core MoMo, chúng tôi cần đồng bộ và xử lý tương ứng ở Core Loyalty, và ngược lại. Tuy nhiên, cũng có những trường hợp ngoại lệ, như user chỉ bị blacklist tại một hệ thống (do yếu tố cá nhân hoặc yêu cầu từ business), hoặc chỉ bị giới hạn ở phạm vi của Loyalty hay trong khoảng thời gian nào đó. Về cơ bản, cơ chế xử lý của chúng tôi dựa trên hệ thống event và value để đảm bảo tính nhất quán chung khi thực thi.

  
  
  

  Tóm gọn lại thì hoàn thành những nhiệm vụ trên đồng nghĩa với việc xây dựng core loyalty đã hoàn tất. Tuy nhiên, trước khi hệ thống chính thức hoạt động, chúng tôi đã chuẩn bị kỹ lưỡng một kế hoạch chuyển giao và nâng cấp nhằm đảm bảo quá trình triển khai diễn ra suôn sẻ.

  Bên cạnh việc cải tiến hệ thống tiền tệ, chúng tôi cũng thực hiện các cập nhật lớn về giao diện và tính năng, giúp cải thiện trải nghiệm người dùng. Dựa trên các phân tích sâu trước đó, những thay đổi này đảm bảo sự thống nhất trong trải nghiệm trên toàn hệ thống của Loyalty trong MoMo, chứ không chỉ về mặt kỹ thuật. Tuy nhiên, bài viết này sẽ chỉ tập trung vào khía cạnh chủ đề hệ thống tiền tệ mà tôi tham gia xử lý.

  
  
  
  
  

  Start as a Concept, Built as a System, Delivered as a Solution

  Điểm khác biệt lớn nhất của Core Loyalty là nó không xử lý trực tiếp các giao dịch tiền tệ thực sự. Điều này đồng nghĩa với việc nhiều rào cản kỹ thuật tài chính đã được lược bỏ, mở ra không gian để chúng tôi khám phá thêm các tiềm năng. Và một trong những tính năng đáng chú ý nhất chính là khả năng thiết lập multi-pocket (đa ngăn ví).

  Ban đầu, Core Loyalty chỉ được thiết kế với 2 ngăn ví, gồm một ngăn để chứa điểm rank và một ngăn chứa điểm cashback (với tỉ lệ quy đổi 1:1). Tuy nhiên, kiến trúc linh hoạt của hệ thống cho phép chúng tôi dễ dàng tạo ra nhiều ngăn ví mới và tùy chỉnh các phép tính bên trong để ứng dụng vào các tình huống kinh doanh thực tế. Điều này mở ra khả năng Core Loyalty không chỉ là chương trình của MoMo mà còn trở thành một nền tảng Loyalty toàn diện dành cho các khách hàng doanh nghiệp.

  Các ngăn ví riêng có thể được thiết lập và sử dụng các agent riêng biệt để vận hành. Về mặt kinh doanh, điều này đồng nghĩa với việc, ngoài việc triển khai Loyalty program cho chính MoMo, các đối tác của MoMo cũng có thể tùy chỉnh và vận hành các chương trình khuyến mãi độc lập của riêng họ trên nền tảng này. Dưới đây là cách chúng tôi thiết lập mô hình cashback với multi-pocket trên Core Loyalty trong giai đoạn đầu:

  A = Ngăn ví Loyalty, thực hiện theo các giao dịch cashback hiện tại theo chương trình. Ví A đang được thiết lập:

  • Nhận tối đa 10.000đ/giao dịch theo các nhóm khác nhau (tối thiểu theo các nhóm dịch vụ)
  • Nhận tối đa 25.000đ/ngày và 10 lần/tháng.

  B = Ngăn ví CGV, được tạo ra cho campaign mua vé CGV lần đầu sẽ được cashback 10.000đ về Ví. Ví B đang được thiết lập:

  • Chỉ ghi nhận nguồn tiền từ các giao dịch mua vé CGV (theo service id)
  • Luôn nhận 10.000đ/giao dịch tương ứng với điều kiện giao dịch giá trị trên 80.000đ
  • Tối đa 2 giao dịch từ ngày 15/5 đến 30/5.
  • Agent set budget 100 triệu VNĐ, tương đương chương trình chỉ áp dụng cho 10.000 giao dịch.

  C = Ngăn ví Baemin, được tạo ra cho campaign mua Trà sữa sẽ được cashback gấp đôi ở rank hiện tại. Ví C đang được thiết lập:

  • Chỉ áp dụng cho user từ hạng Vàng trở lên
  • User được hoàn tiền gấp đôi giá trị, áp dụng cho mọi giao dịch Baemin bất kỳ trên 200.000đ.
  • Thời gian áp dụng từ 15/5 đến 22/5 (1 tuần).
  • Agent set budget 200 triệu VNĐ, chương trình sẽ áp dụng cho đến khi chạm capset của budget.

  Dù không trực tiếp đồng hành với dự án Loyalty từ đầu cho đến khi mở rộng sau này, nhưng quãng thời gian làm việc tại MoMo đã mang lại cho tôi nhiều hiểu biết quan trọng về cách hệ thống fintech vận hành. Sau này, tôi đã áp dụng những kinh nghiệm này để xây dựng một hệ thống thanh toán luân chuyển giữa fiat và blockchain ở một quy mô nhỏ hơn.

  
  
  

  Bài học thực tế

  Toàn bộ quá trình xây dựng và tối ưu Core Loyalty kéo dài khoảng 3 tháng, tuy không phải là khoảng thời gian quá dài, nhưng ít nhiều chúng tôi cũng rút ra được bài học quan trọng từ quá trình này.

  1. Scalability Matters: Hệ thống thanh toán sớm cần được thiết kế với khả năng mở rộng ngay từ đầu. Việc thiếu tính toán có thể trở thành điểm nghẽn khi số lượng người dùng tăng nhanh. Sau này, khi làm việc với Tencent trong một dự án khác, tôi nhận thấy họ cũng áp dụng tư duy thiết kế hệ thống theo hướng module hóa, đảm bảo mỗi tính năng có thể xử lý lưu lượng giao dịch lên đến 1 tỷ giao dịch mỗi ngày. Nghe có vẻ "nghiêm trọng hóa" khi nghĩ về quy mô này, nhưng thực tế cho thấy đây là yếu tố cần được lường trước ngay từ giai đoạn đầu, đặc biệt khi dự án có thể bất ngờ bùng nổ, và lúc đó việc refactor lại kiến trúc cũ sẽ không dễ tí nào.
  2. Idempotency & Rollback: Trong bài viết này, có một cơ chế tôi không đề cập đến trong hệ thống Core đó chính là rollback, cái này khá quan trọng vì khi giao dịch tài chính có lỗi hoặc bị gián đoạn, cần có cơ chế đảm bảo mỗi giao dịch chỉ thực hiện một lần duy nhất và có thể khôi phục lại trạng thái hệ thống nếu xảy ra lỗi. Ngoài ra việc rollback giúp ích rất nhiều trong việc tối ưu luồng thực thi của hệ thống Core.
  3. Business & Tech Alignment: Một hệ thống tốt không chỉ cần vững về mặt kỹ thuật mà còn phải phù hợp với chiến lược kinh doanh. Việc lựa chọn thiết kế hệ thống cần xem xét cả yếu tố vận hành, chi phí, và trải nghiệm người dùng. Thực tế, Core Loyalty mà tôi tham gia xây dựng tiêu tốn khá nhiều chi phí vận hành, và đôi khi chính điều này lại trở thành rào cản cho sự thành công của dự án. Đối với một người làm product, đây là bài toán cần được cân nhắc kỹ lưỡng trước khi triển khai, đảm bảo hệ thống không chỉ mạnh về mặt kỹ thuật mà còn bền vững về mặt kinh doanh.

  Lời Kết

  Bài viết này tập trung vào việc mô tả lại trải nghiệm thực tế và các giải pháp mà tôi và đội ngũ dự án đã thực hiện, mà không đi sâu vào từng chi tiết của hệ thống Core Banking. Với góc nhìn từ vai trò một Product Manager hơn là một chuyên gia kỹ thuật, điều này cho phép tôi nhìn nhận vấn đề từ quan điểm của người xây dựng trải nghiệm sản phẩm lẫn chiến lược hệ thống. Hy vọng bài viết sẽ mang lại những thông tin hữu ích cho các bạn, đặc biệt là những ai quan tâm đến việc triển khai các giải pháp tương tự.

  

  Thanks for reading my little story.