The Identify feature enables a plug-and-play subscription overview and acts as the entry point for our other action features such as Cancel.

To get Identify up and running, complete the following steps:

  1. Onboard the user and collect their consent for transaction sharing
  2. Share the user’s transactions with us
  3. We process the transactions and identify the subscriptions that the user is paying for

You also have the option of notifying the user of changes in their subscription spending. For more information, read our section on After action: User messaging.

There are a number of options available for each step and we are happy to work out together what is the best fit for you.

Step 1: User consent

In accordance with GDPR and PSD2 regulations, the user must allow us to fetch accounts and transactions. The consent will unlock fetching transactions for the user. Depending on how the consent is collected will also affect how we retrieve transactions as the two are very closely coupled. This can be done in two different ways:

  • The bank collects user consent before entering application
  • The user provides consent after opening our service

Since users naturally trust their bank to handle their data safely, the ideal solution is that the user’s consent is captured in your app and thereafter shared with us. This minimizes the hurdle for the user to enable the feature. Users tend to be sensitive about sharing their transaction data, and we see that drop-off rate for onboarding users to the Identify feature plummets the more disjointed the onboarding journey is.

If an open banking or PSD2 solution is used for the integration, then we have functionality available to collect the consent from the user and store it on our side.

Good practices
We have seen that the fewer screens the user goes through before seeing their subscriptions, the higher the conversion rate is.

  • Seamless onboarding ✔️
  • Multiple onboarding and authentication pages and redirects ❌

Step 2: Provide the user’s transactions

We recommend that transactions are provided to us through a Premium API, where we’re able to fetch transactions continuously for the user once the user has onboarded. This allows us to process their transactions on a daily basis, automatically detect any changes and inform the user of any changes, including alerting for potential fraudulent subscriptions. A similar experience can be achieved with open banking or PSD2 solutions.

Step 3: Subscription identification

As soon as we have received the transactions for a user, we will process them through our identification engine. The identification engine isolates payments made to known merchants at regular intervals; whether that payment is via direct debit, standing order, credit or debit card, digital wallet or SEPA Credit Transfer. The engine functions as a rule-based system that identifies and aligns transactions to merchants, while interval detection uses an advanced statistical approach to detect subscription intervals and amounts. Machine learning further enhances the accuracy and sensitivity of the solution over time, enabling it to adapt to user behaviour and provide greater insights.

Step 4: Displaying the subscription overview

Depending on your preferred integration option, the subscription overview can currently only be displayed in our WebUI. Please refer to the implementation guide below.

📘

Note, in order to provide a more seamless experience there’s an Identify widget under development. This can be used to provide a more dynamic entry point from your side. Have a look at the beta documentation here.


Did this page help you?