# Managed Flows
source: https://developer.mastercard.com/open-finance-data/documentation/features/user-flows/managed-flows/index.md

#### Overview {#overview}

Managed Flows are hosted by Mastercard Open Finance and guide the user through the connection journey using Mastercard UI. This can include provider selection, consent presentation, authentication, and completion screens, depending on the client type and the bank's requirements.

Managed Flows exist to give partners a pre-built, Mastercard-hosted authorization journey that they can launch with minimal UX and orchestration effort. Instead of designing and maintaining multiple bank-specific handoffs, the partner creates the consent, creates the managed flow, and redirects the end user to a Mastercard-hosted UI that guides them through the required steps before returning the user to the partner application. This provides a streamlined way to onboard users while Mastercard manages the flow mechanics and end-user screens.

In practice, Managed Flows are the default choice because they reduce implementation burden and ongoing maintenance. Mastercard handles provider-specific complexity and updates, while partners get a consistent journey across financial institutions. The model is also designed to support a secure and compliant experience "out of the box," with Mastercard controlling the hosted flow behavior and screens, and the partner integrating primarily through the flow creation, redirect pattern, and callback handling. This aligns with the internal expectation that Managed Flows covers the vast majority of early implementations.

Managed Flows are not a single "one-off" screen set. They represent a managed lifecycle that supports common journeys such as initial account connection (for example, CONNECT_ACCOUNTS) and reauthentication/repair of existing connections (for example, REAUTHENTICATE_CONNECTION), with defined statuses (ACTIVE, AUTHORIZING, COMPLETED, FAILED, EXPIRED, CANCELLED). This lifecycle framing clarifies that Managed Flows are a full authorization workflow construct, not just a UI wrapper, making them the foundation on which optional variations (like suppressing specific screens) can be applied when appropriate.

Screen suppression is not a separate flow type. They are a variation of Managed Flows in which selected Mastercard-hosted screens are intentionally skipped when the client already handles those steps in its own UI or when those screens are not required for that client setup.

#### Why this exists {#why-this-exists}

Managed Flows exist to provide a standard, Mastercard-hosted authorization journey that partners can implement quickly and reliably across many financial institutions. Mastercard owns the hosted UI and orchestrates the steps required to connect accounts and capture consent, so partners do not need to build and maintain provider-specific UX patterns for bank selection, authentication, and consent progression. The result is a predictable integration approach (create flow → redirect user → handle return) where Mastercard manages the complexity and evolution of the hosted journey.

Screen suppression gives clients a middle ground between Self-Hosted Flows and standard Managed Flows. It reduces unnecessary handoffs, supports stronger client branding, and simplifies the user journey without requiring the full implementation effort of a Self-Hosted Flow.

For licensed clients, the main value is often brand continuity. The client can keep the journey focused on its own product experience while Mastercard remains in the background and only hosts the stages that still need to be hosted.

#### Flow type versus SCA approach {#flow-type-versus-sca-approach}

It is important to distinguish flow type from the Strong Customer Authentication (SCA) approach required by the financial institution. The flow type describes who hosts and controls the end‑user UI journey: it is either Managed (Mastercard‑hosted UI) or Self‑Hosted (partner‑hosted UI with Mastercard APIs).

Redirect, Embedded, and Decoupled are SCA approaches. They describe how the bank requires the user to authenticate and approve access (for example: redirecting the user to the bank, collecting inputs in an embedded experience, or approving on a separate channel). These SCA approaches can occur in both Managed and Self‑Hosted flows. They do not indicate who owns the UI overall. They indicate how authentication is performed to satisfy the bank's requirements.
Note: In Self‑Hosted flows you may see platform "next step" instructions (for example REDIRECT, FORM, WAIT) that describe what the partner UI should do next. Those UI step instructions are separate from the bank's SCA approach (Redirect / Embedded / Decoupled).

#### What can be suppressed {#what-can-be-suppressed}

If the client sends a preselected provider ID when creating the Managed Flow, Mastercard does not show the provider bank selection screen and move the user directly to the next required stage in the journey. This capability is relevant for both licensed and unlicensed clients and can help create a more streamlined experience when the provider is already known.

For licensed clients, Mastercard also supports greater flexibility in how the journey is presented. Licensed clients may manage consent within their own UI and can configure whether consent information should be shown within the Managed Flow. For licensed customers, consent information is not displayed by Mastercard by default, as licensed partners typically host consent on their own screens. Mastercard can host consent instead if this is enabled through configuration. In addition, certain completion or success screens after SCA can be omitted so that the user is returned directly to the client experience without additional Mastercard-hosted confirmation pages. This is also the current default behavior for licensed clients: once SCA is completed, no completion screens are shown unless configured otherwise.

You can suppress selected Mastercard‑hosted screens within a Managed Flow when your application already performs those steps (for example, provider selection and/or consent presentation).

This Figma diagram illustrate common screen suppression journeys, showing where the provider selector and certain post‑SCA completion screens may be skipped so the user returns directly to your experience.

For the best viewing experience, choose the **full screen** option.

#### What cannot be suppressed {#what-cannot-be-suppressed}

Embedded authentication stages cannot be hidden in Managed Flows when the bank requires user input such as username, password, PIN, or similar credentials. In Managed Flows, Mastercard must host that stage.

Clients that require full UI control over every stage, including embedded credential collection, must use Self-Hosted Flows instead.

#### Licensed versus unlicensed clients {#licensed-versus-unlicensed-clients}

Unlicensed clients can suppress some screens, such as the provider selector when a provider is preselected, and they can apply theming such as logo and colors. However, required disclosures and consent-sharing screens must remain visible where legally necessary.

Licensed clients have more flexibility. They can use their own bank selector, manage consent in their own UI, and control the design and behaviour of their self-hosted screens to align with their own user experience requirements.

#### Implementation considerations {#implementation-considerations}

If the client wants to render its own bank selector, it must first retrieve the list of providers from Mastercard and use that data to populate the selector. The Managed Flow request should then include the selected provider identifier.

After bank authentication is completed, the user is redirected back to the client journey. For licensed partners, the return step may include limited or no visible Mastercard completion UI, depending on how the journey is configured.

The following table illustrates a typical licensed client journey where the client owns bank selection, Mastercard suppresses the provider selector, and only the required hosted stages remain.

|                                       **Client UI**                                       |                                                               **Mastercard UI**                                                               |                                               **Bank UI**                                               |
|-------------------------------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------------------|
| **1. Select provider** *Client renders its own bank selector using the provider list API* | **4. Provider selector suppressed** *Licensed partner may show consent in its own UI*                                                         |                                                                                                         |
| **2. Present consent** *Licensed partner may show conent in its own UI*                   | **5. Only required hosted stages remain** *Redirect stages continue in bank UI. Embedded stages still appear in Mastercard UI when required.* | **6. Authenticate with a bank** *Bank determines whether the stage is Redirect, Embedded, or Decoupled* |
| **3. Start managed flow** *Create Managed Flow request includes preselected provider ID*  | **7. Completion UI may be minimal** *User can return directly to the partner experience*                                                      | **8. Return a control** *User returns after authentication completes*                                   |

Note: The screen suppression removes selected Mastercard-hosted screens but it does not change the bank required authentication pattern.

###### Table notes {#table-notes}

|     **Element**      |                                                 **Meaning**                                                 |
|----------------------|-------------------------------------------------------------------------------------------------------------|
| Provider selector    | Can be skipped when the client sends a preselected provider ID                                              |
| Consent screen       | May be shown by Mastercard or handled in client UI, depending on the client setup                           |
| Embedded stage       | Cannot be suppressed in Managed Flows if the bank requires the user to enter credentials or other data      |
| Success / completion | Often omitted in flows initiated by licensed customers to return the user directly to the client experience |



# Managed Flows
source: https://developer.mastercard.com/open-finance-data/documentation/features/user-flows/managed-flows/index.md

#### Overview {#overview}

Managed Flows are hosted by Mastercard Open Finance and guide the user through the connection journey using Mastercard UI. This can include provider selection, consent presentation, authentication, and completion screens, depending on the client type and the bank's requirements.

Managed Flows exist to give partners a pre-built, Mastercard-hosted authorization journey that they can launch with minimal UX and orchestration effort. Instead of designing and maintaining multiple bank-specific handoffs, the partner creates the consent, creates the managed flow, and redirects the end user to a Mastercard-hosted UI that guides them through the required steps before returning the user to the partner application. This provides a streamlined way to onboard users while Mastercard manages the flow mechanics and end-user screens.

In practice, Managed Flows are the default choice because they reduce implementation burden and ongoing maintenance. Mastercard handles provider-specific complexity and updates, while partners get a consistent journey across financial institutions. The model is also designed to support a secure and compliant experience "out of the box," with Mastercard controlling the hosted flow behavior and screens, and the partner integrating primarily through the flow creation, redirect pattern, and callback handling. This aligns with the internal expectation that Managed Flows covers the vast majority of early implementations.

Managed Flows are not a single "one-off" screen set. They represent a managed lifecycle that supports common journeys such as initial account connection (for example, CONNECT_ACCOUNTS) and reauthentication/repair of existing connections (for example, REAUTHENTICATE_CONNECTION), with defined statuses (ACTIVE, AUTHORIZING, COMPLETED, FAILED, EXPIRED, CANCELLED). This lifecycle framing clarifies that Managed Flows are a full authorization workflow construct, not just a UI wrapper, making them the foundation on which optional variations (like suppressing specific screens) can be applied when appropriate.

Screen suppression is not a separate flow type. They are a variation of Managed Flows in which selected Mastercard-hosted screens are intentionally skipped when the client already handles those steps in its own UI or when those screens are not required for that client setup.

#### Why this exists {#why-this-exists}

Managed Flows exist to provide a standard, Mastercard-hosted authorization journey that partners can implement quickly and reliably across many financial institutions. Mastercard owns the hosted UI and orchestrates the steps required to connect accounts and capture consent, so partners do not need to build and maintain provider-specific UX patterns for bank selection, authentication, and consent progression. The result is a predictable integration approach (create flow → redirect user → handle return) where Mastercard manages the complexity and evolution of the hosted journey.

Screen suppression gives clients a middle ground between Self-Hosted Flows and standard Managed Flows. It reduces unnecessary handoffs, supports stronger client branding, and simplifies the user journey without requiring the full implementation effort of a Self-Hosted Flow.

For licensed clients, the main value is often brand continuity. The client can keep the journey focused on its own product experience while Mastercard remains in the background and only hosts the stages that still need to be hosted.

#### Flow type versus SCA approach {#flow-type-versus-sca-approach}

It is important to distinguish flow type from the Strong Customer Authentication (SCA) approach required by the financial institution. The flow type describes who hosts and controls the end‑user UI journey: it is either Managed (Mastercard‑hosted UI) or Self‑Hosted (partner‑hosted UI with Mastercard APIs).

Redirect, Embedded, and Decoupled are SCA approaches. They describe how the bank requires the user to authenticate and approve access (for example: redirecting the user to the bank, collecting inputs in an embedded experience, or approving on a separate channel). These SCA approaches can occur in both Managed and Self‑Hosted flows. They do not indicate who owns the UI overall. They indicate how authentication is performed to satisfy the bank's requirements.
Note: In Self‑Hosted flows you may see platform "next step" instructions (for example REDIRECT, FORM, WAIT) that describe what the partner UI should do next. Those UI step instructions are separate from the bank's SCA approach (Redirect / Embedded / Decoupled).

#### What can be suppressed {#what-can-be-suppressed}

If the client sends a preselected provider ID when creating the Managed Flow, Mastercard does not show the provider bank selection screen and move the user directly to the next required stage in the journey. This capability is relevant for both licensed and unlicensed clients and can help create a more streamlined experience when the provider is already known.

For licensed clients, Mastercard also supports greater flexibility in how the journey is presented. Licensed clients may manage consent within their own UI and can configure whether consent information should be shown within the Managed Flow. For licensed customers, consent information is not displayed by Mastercard by default, as licensed partners typically host consent on their own screens. Mastercard can host consent instead if this is enabled through configuration. In addition, certain completion or success screens after SCA can be omitted so that the user is returned directly to the client experience without additional Mastercard-hosted confirmation pages. This is also the current default behavior for licensed clients: once SCA is completed, no completion screens are shown unless configured otherwise.

You can suppress selected Mastercard‑hosted screens within a Managed Flow when your application already performs those steps (for example, provider selection and/or consent presentation).

This Figma diagram illustrate common screen suppression journeys, showing where the provider selector and certain post‑SCA completion screens may be skipped so the user returns directly to your experience.

For the best viewing experience, choose the **full screen** option.

#### What cannot be suppressed {#what-cannot-be-suppressed}

Embedded authentication stages cannot be hidden in Managed Flows when the bank requires user input such as username, password, PIN, or similar credentials. In Managed Flows, Mastercard must host that stage.

Clients that require full UI control over every stage, including embedded credential collection, must use Self-Hosted Flows instead.

#### Licensed versus unlicensed clients {#licensed-versus-unlicensed-clients}

Unlicensed clients can suppress some screens, such as the provider selector when a provider is preselected, and they can apply theming such as logo and colors. However, required disclosures and consent-sharing screens must remain visible where legally necessary.

Licensed clients have more flexibility. They can use their own bank selector, manage consent in their own UI, and control the design and behaviour of their self-hosted screens to align with their own user experience requirements.

#### Implementation considerations {#implementation-considerations}

If the client wants to render its own bank selector, it must first retrieve the list of providers from Mastercard and use that data to populate the selector. The Managed Flow request should then include the selected provider identifier.

After bank authentication is completed, the user is redirected back to the client journey. For licensed partners, the return step may include limited or no visible Mastercard completion UI, depending on how the journey is configured.

The following table illustrates a typical licensed client journey where the client owns bank selection, Mastercard suppresses the provider selector, and only the required hosted stages remain.

|                                       **Client UI**                                       |                                                               **Mastercard UI**                                                               |                                               **Bank UI**                                               |
|-------------------------------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------------------|
| **1. Select provider** *Client renders its own bank selector using the provider list API* | **4. Provider selector suppressed** *Licensed partner may show consent in its own UI*                                                         |                                                                                                         |
| **2. Present consent** *Licensed partner may show conent in its own UI*                   | **5. Only required hosted stages remain** *Redirect stages continue in bank UI. Embedded stages still appear in Mastercard UI when required.* | **6. Authenticate with a bank** *Bank determines whether the stage is Redirect, Embedded, or Decoupled* |
| **3. Start managed flow** *Create Managed Flow request includes preselected provider ID*  | **7. Completion UI may be minimal** *User can return directly to the partner experience*                                                      | **8. Return a control** *User returns after authentication completes*                                   |

Note: The screen suppression removes selected Mastercard-hosted screens but it does not change the bank required authentication pattern.

###### Table notes {#table-notes}

|     **Element**      |                                                 **Meaning**                                                 |
|----------------------|-------------------------------------------------------------------------------------------------------------|
| Provider selector    | Can be skipped when the client sends a preselected provider ID                                              |
| Consent screen       | May be shown by Mastercard or handled in client UI, depending on the client setup                           |
| Embedded stage       | Cannot be suppressed in Managed Flows if the bank requires the user to enter credentials or other data      |
| Success / completion | Often omitted in flows initiated by licensed customers to return the user directly to the client experience |