Goals and SubAccounts

What is the difference between a SubAccount and a Goal?

From a practical perspective, a SubAccount and a Goal are the same. That is, these are all a form of Account. In the Helix model a Goal is an Account just as a SubAccount is an Account.

Why should a Customer have a primary account?

On the account object you'll note the property isPrimary. This denotes the primary account for a customer. This account must not be closed while the Customer is still active in business models that permit multiple accounts, subaccounts, or goals on behalf of a customer. The requirement for a primary account comes from the regulatory and legally permitted flow of funds models with respect to goals and subaccounts.

Common Mistake #1: Not using Helix as System of Record for SubAccounts

A critical mistake to not using Helix to track Goals or Subaccounts is the disruption to flow of funds for these accounts. An example of one such common scenario is the receipt by Helix of a funds deposit. Let's work through a handful of scenarios together.

πŸ“˜

Scenario Background:

TariusDamon has downloaded the new Goal based savings application called "Beta One" that provides a monthly 1% loyalty reward for accounts. In the application, he enters in his information to register the account and then is prompted with a screen to create multiple goals. From this, TariusDamon creates three goals that all expire at the end of the month.

  • Goal 1 - Christmas Savings 2021, with a recurring contribution of $200 at the end of each month
  • Goal 2 - End of Month Party, with a funds transfer every time he visits Starbucks
  • Goal 3 - End of Week Grocery Bill, which he will manually move funds into daily

Scenario 1: Goal Closure for in process sweep payments

TariusDamon closes out Goal 1 and Goal 2. Legally, TariusDamon is now entitled to a dollar amount. However, absent a primary account there is no means to identify which account should receive the funds.

Scenario 2: Developer didn't use Helix as System of Record

TariusDamon's three goals are managed at the application and not in the Core. A deposit of funds arrives to Helix to deposit into the account for $500.00. There is now a financial gap of information between what should be the System of Record and the application TariusDamon is using.

Scenario 3: @TariusDamon's Goal 3 is closed by the bank

FinTech partners with a Bank to deliver banking functionality. The bank has the right and, in some scenarios, the obligation to close accounts on behalf of a FinTech's Customer. The Funds from Goal 3 are closed and moved back to the Customer's External Account. What is the balance @TariusDamon should reflect in "Beta One?"

Common Mistake #2: Not relying on Helix account state

A common mistake we see developers make is attempting to cache-in account and transactional data from Customers as a kind of pseudo-system of record. The critical mistake here is that an account, the balances of that account, the beneficiaries, and other transactional information can all be updated out of band from the application calling the API.

The Helix API Platform is the System of Record for all product used in the API. Enable your developers to focus on solving other problems with the understanding that Helix does the job of keeping track of balances, processing incoming files from other banks, adding transactional information, and managing the key information required to participate in the financial markets.