If the profile does not pass the onboarding tasks, their application is rejected. This means the profile should not be granted access to your product.

If the application is initially approved but goes into review and the profile doesn't pass the incomplete tasks, the application is canceled. This means the profile should no longer have access to your product.

If the application is rejected or canceled, this is the end of the lifecycle in most cases. However, it is possible to revert either decision manually. If a decision to reject an application is reverted, the application goes back to the onboarding process. If a decision to cancel an application is reverted, the application goes into review. Either way, the profile must pass any failed or incomplete tasks before their product application can be approved.

To start the process, create a profile and add a product application to it.

You can do both actions with a single call to the API.

Alternatively, you can create a profile without any applications, then use a separate call to the API to add a product application.

If you create a profile without applications, it automatically applies to any products that have the auto_apply attribute. To see if a product has this attribute, log into the portal, go to Policy Builder > Your products, and select the product. If the New profiles will automatically apply for this product checkbox is selected, the product has the auto_apply attribute. Contact us to remove this attribute from a product.

When you add a new product application, the following happens:

If the profile has multiple product applications, the easiest way to distinguish them is by seeing which product each application is for. This information is contained in the object's product field.

Watch the video

The application status determines whether you need to take action to grant or limit access to your product.

These are the possible statuses:

Listen to the Product status changed webhook to learn when the application status changes.

The Product badge changed webhook also fires whenever the application status changes.

When the status comes back as APPLIED or IN_REVIEW, there may be manual work to do.

Listen to the Manual action required webhook to get a notification whenever a product application needs manual work.

Examples of manual work include adding profile data, running a check to add information to the profile, and passing or failing a task.

This webhook payload tells you what's needed for the product application to progress. You can decide whether to take action or leave it to your users.

If the status has changed from REJECTED to APPLIED or changed from CANCELLED to IN_REVIEW, ongoing monitoring is canceled. You must manually run the PEPs and sanctions screening check or Sanctions and adverse media screening check to resume monitoring for new PEPs, sanctions, or adverse media results. Automated actions may be taking place while the status is APPLIED or IN_REVIEW, for example, when the smart policy is being applied or risk is being calculated. The Manual action required webhook does not send a notification for automated actions. If you want your users to take action, you may want to consider sending them a notification from your system to let them know when and what manual action is required. You may want the check results to influence the next manual action. To learn more, see Get the check result.

GET https://api.passfort.com/4.0/profiles/{profile_id}/applications/{application_id}

{
    "approval_blockers": [ … ],
    "assignments": [ ],
    "flag": "REQUIRES_DATA",
    "flag_history": [ … ],
    "hidden": false,
    "history": [ ... ],
    "id": "33bae6b8-5689-b96b-143c-06e93ab8527e",
    "product": {
        "alias": "forexo_basic",
        "automatically_approve": false,
        "id": "a2e7545b-cb67-7a0e-7108-a444461891a9",
        "name": "Forexo Basic Account"
    },
    "required_tasks": [ ],
    "risk": {
        "breakdown": {
            "category_grouping": [ ],
            "components": [ ... ],
            "missing_required_components": [
                "Email"
            ]
        },
        "is_pending": false,
        "overall": {
            "level": "UNDETERMINED"
        },
        "risk_model": {
            "id": "ca37e39b-b075-0420-68d6-a217010dc685",
            "version": "1980-02-01 00:00:00"
        },
        "thresholds": { ... }
    },
    "status": "APPLIED"
}

{
    "approval_blockers": [
        {
            "blocker_type": "UNDETERMINED_OUTCOME",
            "blocking_element": {
                "child_elements": { ... },
                "element_type": "BRANCH",
                "id": "cd37ca40-6f7a-45d1-a4cf-df66bcb6f583",
                "matcher": {
                    "include": [
                        "GBR"
                    ],
                    "type": "STRING_LIST_INCLUDES"
                },
                "name": "Is from UK?",
                "property": {
                    "type": "ADDRESS_COUNTRY"
                }
            }
        }
    ],
    "assignments": [ ],
    "flag": "REQUIRES_DATA",
    "flag_history": [ ... ],
    "hidden": false,
    "history": [ … ],
    "id": "1fa5b230-ff13-11e9-af09-26c2e3647646",
    "product": {
        "alias": "forexo_basic",
        "automatically_approve": false,
        "id": "0fa0a038-e048-11e9-8b30-7a2630ac864b",
        "name": "Forexo Basic Account"
    },
    "required_tasks": [ ],
    "status": "APPLIED"
}

It's best practice to display the current processing state in your systems so your users know what's happening with the product application.

Every product application in the applications array has a flag field, which indicates what's currently happening to the application or what needs to be done for the application to progress to the next status.

The possible values for the flag field are listed here. Only one flag is returned for a product application. If multiple flags apply, the first applicable flag in this list is returned:

Listen to the Product badge changed webhook to get a notification whenever the flag changes.

The Product badge changed webhook also fires whenever the product status changes, so if you're listening to this webhook, you do not need to listen to the Product status changed webhook.

You may want the results of a check to influence the next manual action.

For example, take the Verify identity task that has two associated checks: Electronic identity check and ID verification.

Because an Electronic identity check typically has a higher pass rate than an ID verification check, you might want to configure your smart policy to run the Electronic identity check automatically, and then build your integration so the ID verification check is run via a call to the API whenever the Electronic identity check fails or returns an error.

To get check results whenever a check is run, use the Check completed webhook.

Users can run additional checks, so we recommend running a check via the API only once. We don't recommend using this webhook to sync the result of every check to your back office because this information is easy for users to see, with more detail, in Passfort.

Profile data can change at any time during the application lifecycle. This can happen in Passfortand it may also happen in your systems.

It's best practice to ensure all data in your systems and Passfort match. Learn how to sync profile data with your system data.

If you're using Risk, you likely want to display it in your back office.

The risk level is always determined when the product application is first added to the profile.

It may also change during the application lifecycle. The application risk level is re-evaluated automatically whenever the profile's data is changed.

To get a notification when an application's risk level is first determined or changes, use the Risk level changed webhook.