Skip to main content

Member Use Cases

You can opt in to setting the use_cases field in applicable requests so each member has an associated use_case to:

  • Ensure only the data associated with the use case for that member (PFM or Money Movement) is returned.
  • Filter a user’s data through a single use_case, even if data relating to a different use_case is in our system.

Members with the PFM use case will aggregate data the same as before. Our Personal Finance Management and Financial Insights products will only reflect data for members with the PFM use case.

Members with the MONEY_MOVEMENT use case won’t aggregate transaction data.

For how this affects the Connect Widget, see the Connect Widget docs.

If you're using the Connections Widget, you can set the connections_use_case_filter parameter to true so the widget only shows connections (members) that have the use_cases you defined in the same request. For example, if you set connections_use_case_filter to true and use_cases to ["PFM"], then only members containing the PFM as one of its use_cases will show in the widget. If you make the same request but set use_cases to ["PFM", "MONEY_MOVEMENT"], then members with either use case will show in the widget.

Required Actions​

This work requires MX to enable this functionality. Additionally, for existing integrations, MX will backfill your existing members to set their use_cases field.

You must ensure that each of the following requests sets the use_cases field to either PFM and/or MONEY_MOVEMENT:

If making requests to one of the following Nexus GET endpoints, the associated member(s) must have PFM as a use_case, otherwise a 403 will return:

The following endpoints in Nexus accept a single use_case query parameter that you can set to either MONEY_MOVEMENT or PFM. For example, if you're using the List Members request, this would look like either GET /members?use_case=PFM or GET /members?use_case=MONEY_MOVEMENT.

On this page