03-Account

Building a super-app ecosystem begins with how system accounts are defined. While traditional customer and merchant account types are great, they do not reflect the true meaning of an integrated ecosystem. Therefore, it’s essential to change the account definition from rigid definitions to an adaptable model that emulates real-life scenarios. As humans, we have different skill sets and preferences, and the account model should be built to absorb multiple criteria and definitions the same way we deal with each other on daily bases.

As shown in the sample diagram, a system account is a group of tiny modules used to define and differentiate each account configured on the system.

Groups

A group is a logical container that holds system accounts and is used for reporting or applying bulk settings to multiple accounts in one click.

Groups could be used to activate, lock or block linked accounts, or to define internal system interactions where the system may force Group A not to transact with Group B. This approach allows for more flexibility and customization while configuring accounts based on various criteria such as user preferences, business needs, and transaction types.

Overall, the account model is a crucial component when building a super-app ecosystem, and a flexible and adaptable approach will enable a more seamless and personalized experience for users. The use of groups also provides more control and customization options for businesses, enabling them to manage their accounts more efficiently and effectively.

Account

The system account can be used to access system services, sell goods and services, or for an employee who is administering the system. All accounts have the same internal modules, but the values and allowed access may differ. This flexible design can easily accommodate users who want to use the system wallet for personal or business purposes, as well as actual administrators of the system.

Additionally, any defined account can own their own marketplace to sell products or services, trade credits with other accounts, family, and friends, and use their credits to purchase items from others without the need to create multiple accounts or different access on the system.

This approach enables users to have more control over their accounts and the ability to seamlessly transition between personal and professional use. It also provides a new level of flexibility for businesses to create customized account settings for their employees, giving them access to the tools and services they need to be most efficient.

Information module

Information module of the system includes essential account information, historical data, lists, and preferences for each user as outlined below:

  • Main info: This module holds account main information such as full name, address, contact details, or self-ID number. For business accounts, this module holds company name, commercial register number, and taxation ID.
  • Credentials: This module is isolated for security purposes and stores user access tokens, passwords, PIN numbers, and session IDs.
  • Lists: Lists are customizable lists created by the account holder to group family, friends, or colleagues for individuals. While for corporate accounts, lists may be used to group employees or partners accounts.
  • Schedule: This date-based module is used to save system-generated payment or installment due dates, user-added birthday events, or friendly group saving -ROSCA- payments. Users can also plan personal commitments such as rents, utility bills, or friendly transfers. Corporate accounts will use the same module to schedule payroll disbursements or collection records if applicable.
  • Score card: This module is the scorecard, which displays the output of the scoring module for each registered account. The score generation technique will be explained in the scoring module part, but it’s worth mentioning that this score impacts the user limits and allowed services on the system.

Profile

Profiles are a type of logical container used to control accounts that share the same access, counters, or limits. They allow linked consumer accounts to:

  • Access enabled services based on defined eligibility
  • Navigate the marketplace and purchase all published products
  • Pay bills or settle outstanding amounts
  • Send and receive money for other registered consumer accounts
  • Access services via published interfaces, such as USSD, mobile apps, or consumer portals, if available.

Business accounts enjoy all the same benefits as consumer accounts, and in addition, they can:

  • Collect funds from purchase requests
  • Trade with other merchant accounts
  • Offer cash in and out services to consumers
  • Add, edit, or remove items from their owned marketplace
  • Change product or service pricing or fees
  • Run campaigns, promotions or apply discounts.

In addition to controlling service accessibility and availability, profiles are also used to set limits on accounts. This is an important part of fraud prevention and anti-money laundering (AML) controls, which are mandated in multiple countries. Limits and counters should cover the following:

  • Maximum daily amount per service, where sending money is considered one service while paying bills or making a purchase is another.
  • Maximum monthly amount per service.
  • Maximum daily transaction count.
  • Maximum monthly transaction count.
  • Profile+ and Profile additional limits which is used dynamically to control the account based on scoring module output.

By setting these limits, businesses can prevent fraudulent activities and ensure that transactions remain within legal and ethical boundaries. It is important for businesses to stay up to date with AML regulations and implement appropriate controls to prevent financial crimes.

Source of fund

Building a super-app requires a stable and fully functioning payment platform to complement the necessary financial activities for closing the orders cycle internally. This will enable the overall solution to mark completed orders, which is a crucial piece of information required for determining the customer’s next ordering advertisement. Additionally, completing payments will result in an additional profit margin, as it includes the payment commission value. Therefore, it is essential to have a reliable payment system in place to ensure the smooth operation of the super-app and maximize profitability.

Main wallet

A perfect super-app requires a flawless payment platform with multi-wallet functionality to cater to all potential use cases. The internal wallet system should make use of main and sub-wallets concept.

The main wallet should not have any usage restrictions, apart from adhering to AML and fraud controls. Customers should have the freedom to deposit, withdraw, transfer, or pay for orders from their main wallet as long as they are performing legitimate transactions.

Sub wallet

On the other hand, a sub-wallet is similar to a main wallet but may have additional restrictions. For instance,

  • Loyalty wallet: a loyalty sub-wallet could be utilized to receive gift or loyalty balances that are rewarded upon certain usage or activity. The usage of loyalty balances should have some restrictions to control the financial impact. Typically, loyalty balances should not be transferred or withdrawn and may only be used to purchase pre-defined products with good margins or for internal products with lower production or shipping costs.
  • Outsourced wallet:  another form of a sub-wallet is an outsourced wallet, which is operated, refilled and controlled by a third-party. For example, this might be a payroll wallet or a government aid or support fund wallet, where all use cases are subject to a custom pricing or fee model based on a bilateral agreement with the third party.
  • Exchange wallet: another type of sub-wallet is an exchange wallet, which can be used to store foreign currency balances and allow only certain access to this wallet balance or provide exchange services within the same ecosystem. This feature can provide an additional benefit for countries with high tourist volumes.
  • Additional examples: Sub-wallets can be utilized in unlimited scenarios, and their potential usage cannot be limited or listed. Other examples of sub-wallet use cases include:
    • Billing sub-wallets, which are limited to paying bills and utility payments.
    • Promotion wallets, which store gift credits.
    • Internal benefit wallets, which are funded by a business entity and can only be used at pre-defined merchants.

In summary, sub-wallets provide a flexible and customizable solution for various payment needs and can be tailored to suit specific use cases, making them an integral part of a perfect payment platform for a super-app.

Mapping account

In addition to the financial benefits of having an internal wallet within the super-app itself, the ecosystem should extend to other possible accounts that customers may have, including but not limited to:

  • Bank accounts: any current or savings bank account with direct bank integration can support transferring existing funds from the bank account to our super-app wallets in a digital refill request. Moreover, the system should support a direct debit request towards a linked bank account against an online purchase or payment request.
  • Card accounts: with a load from card function or online card processing form, the system will enable customers to pay for their orders via card account.
  • Loan accounts: in the form of a loan, BNPL, or any digital finance account, the integration should be supported in the same way as a card or bank account. Upon paying for an order, the system will send a limit consumption request to the loan provider, and once a successful response is received, the order will complete successfully, and the fulfillment process will take place directly.
  • Loyalty: or external point system integration
  • Additionally, the ecosystem is flexible enough to onboard any other possible liability account, such as a loyalty or external point system integration. The system should avail the ability to use the integrated account in refill activity by loading or transferring credits from the mapping account to the system’s internal wallet. Or, it can use the account balance directly as a form of payment upon closing a transaction or paying for an order.

With this unique design and combined sub-wallet and mapping account features, the system can lock the refill values from being withdrawn or transferred to other accounts, which eliminates the credit liquidity risk for credit accounts.