• new Add support for additional_data field on company discoveries. This field will contain the same data as the company section of the case.
• GET /v2/accounts/{aid}/cases/{cid}

• new Add expired status to contract. Expired contracts can be re-opened by using POST /v2/accounts/{aid}/cases/{cid}/contracts/{contract_id}, but will require all signatories will have to sign the contract even if they had signed before, closed contracts cannot be re-opened.
• GET /v2/accounts/{aid}/cases/{cid}/contracts/{contract_id}
• GET /v2/accounts/{aid}/cases/{cid}

• new Add a new check identity_verification to cases. This check will be used to verify the identity of a person in the case. Cases with this check will have a identity_verification_urls field in the urls field of the case details. This field will contain the URL to initiate the identity verification process. After verification is completed the user will be redirected to the declaration page, optionally they can also be redirected to a custom URLvia setting the redirect_url param in the check options. The case details has been updated to contain a identity_verifications field which will contain a list of identity verifications for the case.
• GET /v2/accounts/{aid}/cases/{cid}
• GET /v2/accounts/{aid}/cases/{cid}/identity-verifications/{verification_id}/initiate
• GET /v2/accounts/{aid}/cases/{cid}/identity-verifications

• new Add support for POSSIBLE_ULTIMATE_BENEFICIAL_OWNERS flag in ultimate_beneficial_ownership check. This field will contain the information about possible ultimate beneficial owners missed during declaration.
• GET /v2/accounts/{aid}/cases/{cid}

• new Add support for filtering case events on event type.
• GET /v2/accounts/{aid}/cases/{cid}/events

• new Add new check flag DISCOVERY_UPDATED on company and ultimate_beneficial_ownership checks. This flag will be returned when the discovery information has been updated.

• new Add new field sub_event_type on webhook events that will contain more information on the information that triggered the event.

• new Add support for signatory adding, removing and updating on case agent edits. This will allow agents to edit signatory information on a case.
• POST /v2/accounts/{aid}/cases/{cid}/agent-edits

• new Add support for bank_account editing and updating on case agent edits. This will allow agents to edit bank account information on a case.
• POST /v2/accounts/{aid}/cases/{cid}/agent-edits

• new Add support for getting presigned urls for accessing any file uploaded to Quickr. This can be used to download, share or view the file.
• GET /v2/accounts/{aid}/files/{fid}

• new Add support for automations on cases. Automations can perform actions on a case based on different case triggers, currently only case_status_change is supported. Automations can perform actions like updating the status of the case based on certain conditions. Automations that are to be run on a case can be referenced in the automations field on the case.
• POST /v2/accounts/{aid}/automations
• GET /v2/accounts/{aid}/automations
• GET /v2/accounts/{aid}/automations/{atid}
• PUT /v2/accounts/{aid}/automations/{atid}
• POST /v2/accounts/{aid}/cases
• GET /v2/accounts/{aid}/cases
• GET /v2/accounts/{aid}/cases/{cid}

• new Add support for status_updated_reason field on case and case details.
• POST /v2/accounts/{aid}/cases
• GET /v2/accounts/{aid}/cases
• GET /v2/accounts/{aid}/cases/{cid}
• new Add support for R-1/P6M and R-1/P2Y duration options for checks.
• POST /v2/accounts/{aid}/cases
• GET /v2/accounts/{aid}/cases
• GET /v2/accounts/{aid}/cases/{cid}

• new Add support for status_updated_by field on case and case details.
• POST /v2/accounts/{aid}/cases
• GET /v2/accounts/{aid}/cases
• GET /v2/accounts/{aid}/cases/{cid}

• new Add support for triggering rediscovery on a case.
• POST /v2/accounts/{aid}/cases/{cid}/rerun-discovery

• new Add redirect_url support to signatory check. This field will contain the URL to redirect the signatory to after signing the contract.
• POST /v2/accounts/{aid}/cases
• GET /v2/accounts/{aid}/cases
• GET /v2/accounts/{aid}/cases/{cid}

• new Add reason to politically_exposed_person prefill. This field will contain the reason for the declaration of being/affiliated to politically exposed person.
• POST /v2/accounts/{aid}/cases
• GET /v2/accounts/{aid}/cases
• GET /v2/accounts/{aid}/cases/{cid}
• GET /v2/accounts/{aid}/cases/{cid}/declarations/{did}
• PUT /v2/accounts/{aid}/cases/{cid}/declarations/{did}

• new Add support for adverse-media note section type.
• POST /v2/accounts/{aid}/cases/{cid}/notes
• GET /v2/accounts/{aid}/cases/{cid}/notes
• PATCH /v2/accounts/{aid}/cases/{cid}/notes/{nid}

• new Add support for new keyword to support creating a new contract, if the contract does not exist.
• POST /v2/accounts/{aid}/cases/{cid}/contracts/

• new Add support for creating cases for Denmark companies and persons.
• POST /v2/accounts/{aid}/cases
• GET /v2/accounts/{aid}/cases
• GET /v2/accounts/{aid}/cases/{cid}
• GET /v2/accounts/{aid}/cases/{cid}/declarations/{did}
• PUT /v2/accounts/{aid}/cases/{cid}/declarations/{did}

• new Add support for website check in cases. Currently this is only supported for cases with declared website_url within the payment_details section. The idea is that the check will continuously monitor the website for changes, including changes in type of business, traffic, and other relevant information.
• POST /v2/accounts/{aid}/cases
• GET /v2/accounts/{aid}/cases
• GET /v2/accounts/{aid}/cases/{cid}

• new Add support for exclude parameter in GET /v2/accounts/{aid}/cases to exclude certain fields from the response.
• GET /v2/accounts/{aid}/cases/

• new Add support for POSSIBLE_FAMILY_RELATIONS flag in ultimate_beneficial_ownership prefill. This field will contain the information about possible family relations between the ultimate beneficial owners.Also adds support for detecting manually added ubos.
• GET /v2/accounts/{aid}/cases/{cid}

• new Add addition_reason to ultimate_beneficial_ownership prefill. This field will contain the reason for the addition of the ultimate beneficial owner.
• POST /v2/accounts/{aid}/cases
• GET /v2/accounts/{aid}/cases
• GET /v2/accounts/{aid}/cases/{cid}
• GET /v2/accounts/{aid}/cases/{cid}/declarations/{did}
• PUT /v2/accounts/{aid}/cases/{cid}/declarations/{did}

• new Add support for fetching case discoveries by case id. This will return a list/extended list of discoveries made on the case. The extended list will contain more information as compared to discoveries in the case details.
• GET /v2/accounts/{aid}/cases/{cid}/discoveries

• new Add support for PARENT_COMPANY_CHANGED flag in company checks. Which will be returned if a sub_unit company has changed its parent company.
• GET /v2/accounts/{aid}/cases/{cid}

2024-03-06

• new Add support for THIRD_PARTY_API_ERROR and INTERNAL_API_ERROR flags. These flags will be used when a check encounters an error during execution.
• GET /v2/accounts/{aid}/cases
• GET /v2/accounts/{aid}/cases/{cid}

• new Add support for full report from Creditsafe in json format on credit_score discovery.

• new Add support for NOT_STARTED check status. This status will be used when a check has not been started and is not yet ready to be started.
• breaking Check status behavior has been updated and will no longer be FAILED when the check has completed and the check contains some flags. The status will be COMPLETED instead and the flags can be used to determine the status of the check.
• GET /v2/accounts/{aid}/cases
• GET /v2/accounts/{aid}/cases/{cid}

• new Add support for FORCED_LIQUIDATION company status, in company additional details
• POST /v2/accounts/{aid}/cases
• GET /v2/accounts/{aid}/cases
• GET /v2/accounts/{aid}/cases/{cid}

• new Add the entity_type field on company prefill to add support for companies with subunits.When a case for a subunit company is created it will return with it the parent company information in thecompany section.
• new Add the norwegian_sub_unit_company type on company section additional_data field to include information about the subunit(s) of a company.
• GET /v2/accounts/{aid}/cases/{cid}
• GET /v2/accounts/{aid}/cases/{cid}/declarations/{did}
• PUT /v2/accounts/{aid}/cases/{cid}/declarations/{did}
• POST /v2/accounts/{aid}/cases

• new Add support for querying account usage data. The root or partner account can query usage data for all accounts under it, and the account can query its own usage data. The response will contain the response in csv format.
• GET /v2/accounts/{aid}/accounts/{aid}/reports}

• new Add support for search_results in adverse_media check. This field will contain search results with a higher risk score.
• new Add support for external_ratings in adverse_media discovery, which will contain ratings from external sources.
• GET /v2/accounts/{aid}/cases/{cid}

• new Add support for approved_restricted_prohibited in checklists as a valid answer to a checklist item.
• POST /v2/accounts/{aid}/checklist
• GET /v2/accounts/{aid}/checklist
• GET /v2/accounts/{aid}/checklists/{chkid}
• PUT /v2/accounts/{aid}/checklists/{chkid}
• POST /v2/accounts/{aid}/cases/{cid}/agent-checklists

• new Add support for search_results in adverse_media check. This field will contain search results with a higher risk score.
• new Add support for external_ratings in adverse_media discovery, which will contain ratings from external sources.
• GET /v2/accounts/{aid}/cases/{cid}

new Add support for agent_checklists when creating the case. This this field will contain any required checklists that the agent needs to perform and are required to be completed before a case can be approved.

• POST /v2/accounts/{aid}/cases

new Add support for checklists. Create checklists that can be used in case checklist checks. Add agent checklist action where the agent can update the "answer" to an item in the checklist. A case that have a checklists check will require that the checklist is completed before the agent can approve the case. The case details have been updated with agent_checklists that will list the checklist actions registered by the agent

• POST /v2/accounts/{aid}/checklist
• GET /v2/accounts/{aid}/checklist
• GET /v2/accounts/{aid}/checklists/{chkid}
• PUT /v2/accounts/{aid}/checklists/{chkid}
• POST /v2/accounts/{aid}/cases/{cid}/agent-checklists

new Add support for a new adverse_media check. This check will return a list of adverse media articles that match the information on the case.

• POST /v2/accounts/{aid}/cases
• GET /v2/accounts/{aid}/cases
• GET /v2/accounts/{aid}/cases/{cid}

new Add support for declaring DK and FI bank accounts on cases.

• POST /v2/accounts/{aid}/cases
• GET /v2/accounts/{aid}/cases/{cid}
• PUT /v2/accounts/{aid}/cases/{cid}/declarations/{did}
• GET /v2/accounts/{aid}/cases/{cid}/declarations/{did}

new Add support for payment_information in agent_edits to allow agents to edit payment information on a case.

• GET /v2/accounts/{aid}/cases/{cid}/agent-edits
• GET /v2/accounts/{aid}/cases
• GET /v2/accounts/{aid}/cases/{cid}

new Add support for including additional data points for a company in sections. Add management to additional_data.

• GET /v2/accounts/{aid}/cases/{cid}
• GET /v2/accounts/{aid}/cases/{cid}/declarations/{did}
• PUT /v2/accounts/{aid}/cases/{cid}/declarations/{did}
• POST /v2/accounts/{aid}/cases

• new Add support for agent edits change set on the notes object. This field will contain the changes made by the agent-edits call
• breaking The agent_edits field on the notes object has been removed in favor of agent_edits_change_set.
• GET /v2/accounts/{aid}/cases/{cid}/notes
• POST /v2/accounts/{aid}/cases/{cid}/notes
• PATCH /v2/accounts/{aid}/cases/{cid}/notes/{nid}

• new Add enable_declaration_notifications and enable_signing_notifications to case actions to enable/disable email notifications for case declaration and signing.
• breaking enable_signing_notifications is now required to when to have the same behavior as signing notifications before this change.

• POST /v2/accounts/{aid}/cases
• GET /v2/accounts/{aid}/cases/{cid}

new Add bank_clearing_number and group_id to bank_account section in case. Allow multiple bank accounts in one case.

• POST /v2/accounts/{aid}/cases
• GET /v2/accounts/{aid}/cases/{cid}
• GET /v2/accounts/{aid}/cases/{cid}/declarations/{did}
• PUT /v2/accounts/{aid}/cases/{cid}/declarations/{did}

new Add support for agent edits on cases which allows agents to edit declarations. Currently only supports overriding the ultimate_beneficial_ownership declaration information.

• GET /v2/accounts/{aid}/cases/{cid}/agent-edits

new Add support for immediate one-off check schedules on cases.

• GET /v2/accounts/{aid}/cases/{cid}/schedule-checks

new Add new parameter customer_type to GET /v2/accounts/{aid}/cases to filter cases by customer type.

• GET /v2/accounts/{aid}/cases

new Introduce financial_statements in company section additional_details to include financial statements for company cases.

• GET /v2/accounts/{aid}/cases
• POST /v2/accounts/{aid}/cases
• GET /v2/accounts/{aid}/cases/{cid}

new Add tax_residencies property to cases on individuals.

• POST /v2/accounts/{aid}/cases

new Add support for creating declaration urls on un-declared cases. Currently, this is only supported for cases with perform_checks action.

• POST /v2/accounts/{aid}/cases/{cid}/declarations

new Introduce actions on case creation. This field controls the behavior of the case. With perform_checks or request_declaration options.

• GET /v2/accounts/{aid}/cases
• POST /v2/accounts/{aid}/cases
• GET /v2/accounts/{aid}/cases/{cid}

new Add support for new signatory signing option CHAIRMAN_AND_BOARD_MEMBER

new Add file_id to AgreementPrefillData to include an uploaded agreement file in the agreement prefill.

• GET /v2/accounts/{aid}/cases
• POST /v2/accounts/{aid}/cases
• GET /v2/accounts/{aid}/cases/{cid}
• GET /v2/accounts/{aid}/cases/{cid}/declarations/{did}
• PUT /v2/accounts/{aid}/cases/{cid}/declarations/{did}

new Add support for new signatory signing option PROPRIETOR

new Add support for payment_information check with merchant category code lists.

• POST /v2/accounts/{aid}/cases
• GET /v2/accounts/{aid}/cases/{cid}

new Add support for updating case checks schedule

• PATCH /v2/accounts/{aid}/cases/{cid}

new Add support for requesting company ownership by case Id. Also adds a url to the case object that can be used to retrieve the ownership information.

• GET /v2/accounts/{aid}/cases/{cid}/ownerships/{oid}

new Add support for initiating new contract signing.

• POST /v2/accounts/{aid}/cases/{cid}/contracts/{contract_id}

new Add support for specifying language when creating a case.

• POST /v2/accounts/{aid}/cases

new Add support for creating case from a template.

• POST /v2/accounts/{aid}/cases

new Add support for managing case templates

• POST /v2/accounts/{aid}/templates
• GET /v2/accounts/{aid}/templates
• GET /v2/accounts/{aid}/templates/{tid}
• PATCH /v2/accounts/{aid}/templates/{tid}
• DELETE /v2/accounts/{aid}/templates/{tid}

new Add support for creating case on individuals.

• POST /v2/accounts/{aid}/cases

new Add support for exporting case events. Only supports exporting to a json file.

• POST /v2/accounts/{aid}/cases/{cid}/events/export

new Add support for notifications on case details

• GET /v2/accounts/{aid}/cases/{cid}

new Add customers details to Case object which contains the current information about the customers declared on the case such as company information.

• GET /v2/accounts/{aid}/cases

new Add percent_voting_shares and percent_voting_shares_range fields to ultimate_beneficial_ownership prefill. This field will contain the percentage ownership shares of the ultimate beneficial owner.

• GET /v2/accounts/{aid}/cases
• POST /v2/accounts/{aid}/cases
• POST /v2/accounts/{aid}/cases/{cid}
• GET /v2/accounts/{aid}/cases/{cid}
• GET /v2/accounts/{aid}/cases/{cid}/declarations/{did}
• PUT /v2/accounts/{aid}/cases/{cid}/declarations/{did}

new Add support for filtering cases on case ID with the search parameter.

• GET /v2/accounts/{aid}/cases

new Add support for attachments in unsigned contracts. This field will contain the contract to be signed by the signatory.

• GET /v2/accounts/{aid}/cases/{cid}/contracts/{contract_id}

new Add branding images and company details of an account to UserAccount object.

• GET /v2/account/user

new Add unique flags for check summary when retrieving cases.

• GET /v2/accounts/{aid}/cases

new Add support for adding commitment data to subscription in Account object.

• POST /v2/accounts/{aid}/accounts
• PATCH /v2/accounts/{aid}/accounts/{id}/admin

new Add support for settings field in Account object. Currently only inspect_mode is supported.

• POST /v2/accounts/{aid}/accounts

new Add support for filtering cases by new query parameters: country, sort_by, and sort_order. search has also been extended to support search on organization number and name of a company

• GET /v2/accounts/{aid}/cases

new Include partner.type in Account. This field contains the information about the partner type of the account.

• GET /v2/accounts/{aid}/accounts

new Include name in Account. This field will contain the name of the account. Fallback to company.name if not set. This field can be set when creating and updating a account.

• GET /v2/accounts/{aid}/accounts
• POST /v2/accounts/{aid}/accounts
• PATCH /v2/accounts/{aid}/accounts/{id}/admin

new Include form_submitter in Case. This field will contain the information about the user who submitted the form.

• GET /v2/accounts/{aid}/cases

new Add support for filtering accounts by new query parameters: created_by, type, company.country and status

• GET /v2/accounts/{aid}/accounts

new Add support for specifying type and status when creating new and updating account

• POST /v2/accounts/{aid}/accounts
• PATCH /v2/accounts/{aid}/accounts/{id}/admin

new Add support for subscription field in Account object. This field will contain the information about the subscription enabled on the account and products available for reseller accounts.

• POST /v2/accounts/{aid}/accounts
• PATCH /v2/accounts/{aid}/accounts/{id}/admin

new Add support for ANY_TWO_BOARD_MEMBERS as a signatory signing option.

new Add support for signed_result field in signed contract object. This field will contain the information about the signee from the signing provider. Currently 'BankID' is the only supported signing provider.

breaking background_color_email in branding is removed in favor of background_color_header.

new Add support for COMPANY_TYPE_NOT_SUPPORTED flag in ultimate_beneficial_ownership and credit_score checks.

new Add support for pdf_logo in branding which will be used in all generated contracts.

breaking The generated contracts will no longer use the logo field in branding and will use pdf_logo instead.

new Extend notes section types to include credit_score, case_approved and case_declined.

new Add declared_at field to the cases for both case lists and case details.

new Add support for additional_details in sections for swedish_company, also adds industry_sectors for swedish companies.

new Add support for SanctionedOrganizationRecord in sanction checks which returns a list of sanctioned organizations that match the provided information.

new Add support for current_information field in case details.

new Add support for details fields in case checks to provide additional information to the check flags. Currently we only support DATA_MISMATCH flag.

Authentication

See Authentication for more information on how to authenticate your requests. TLDR; You need to get an API key from the dashboard and use it to request an access token which you can use to authenticate your requests. It is recommended to start with the test API key and switch to the live API key when you are ready to go live.

Note: The API key is only used to request an access token and is not used to authenticate your requests.

const BASE_URL = "https://api.eu.quickr.no/v2/accounts/${ACCOUNT_ID}";
const ACCOUNT_ID = TQ - ACCOUNT - ID - HERE;
const apiKey = YOUR - API - KEY - HERE;
async function getAccessToken(apiKey) {
    const response = await fetch(`${BASE_URL}/auth/token`, {
        method: "POST",
        headers: {
            Authorization: `Bearer ${apiKey}`,
        },
    });

    const { access_token } = await response.json();

    return access_token;
}

const accessToken = await getAccessToken(apiKey);

API Endpoints

The API is available at https://api.eu.quickr.no/v2/. All endpoints are prefixed with /v2/accounts/ACCOUNT_ID/ and are relative to the base url.

The examples are written in Javascript and can be run on any platform that supports the fetch API i.e Node.js, Browser, etc.

Some common use cases for the API are:

• Getting public information about a company
• Running one-off checks like sanctions or politically_exposed_person on a person or company.
• Onboarding customers to your platform.
• Ongoing due diligence checks on a person or company.

In Quickr, you can think of a case as a folder for your customer. It contains all the information about your customer, the checks you want to perform on your customer, and the results of those checks as well any discoveries and/or declarations made by your customer.

A case contains three main parts:

• checks: This field contains the checks you wish to perform on your customer. For example, a sanction would check if your customer is on any sanction lists, more on that here.

  Note: Some checks require specific sections to be present. Think of it as what the check should be performed on. Eg. Run pep on the company and signatories.

• sections: This field primarily controls what kind of information to have on your customer. For example, if you want to have company information on your customer, you would add a company section to the case.

• prefills: This field contains the information you already have about your customer. Quickr will also populate the prefills with information it finds from public registries and other third party sources.

We will start by creating a case that runs a sanction and company check on a company and it's board members. To do this, we will need to create a case with a company section, a sanction check, and a company prefill.

const BASE_URL = "https://api.eu.quickr.no/v2/accounts/${ACCOUNT_ID}";
const ACCOUNT_ID = TQ - ACCOUNT - ID - HERE;

// step 1: Authenticate
const token = await getAccessToken(apiKey);

// step 2: Create a case
const response = await fetch(`${BASE_URL}/cases`, {
    method: "POST",
    headers: {
        Authorization: `Bearer ${token}`,
        "Content-Type": "application/json",
    },
    body: JSON.stringify({
        checks: [
            {
                type: "sanction",
            },
            {
                type: "company",
            },
        ],
        sections: [
            {
                type: "company",
            },
            //  Add a signatory section to run the sanction check on the company's board members and persons of authority.
            {
                type: "signatory",
            },
        ],
        prefills: [
            {
                type: "company",
                data: [
                    {
                        organization_number: "919656395",
                        country: "NO",
                    },
                ],
            },
        ],
        actions: ["perform_checks"],
    }),
});

Now that we have the case created, you will notice that the signatory and company prefills have been populated, and the case has a status of PROCESSING_DETAILS this means that Quickr is running the checks on the data found in the prefills. After a few seconds, the status will change to READY_FOR_REVIEW and the checks is populated with the results of the checks. More on checks here.

So far we have seen how to run a one-off check on a customer. In this section, we will see how to onboard a customer to your platform.

Say you run a delivery service and you want to onboard a new restaurant to your platform, you might want to know if the restaurant is a legitimate business, actual owners, credit score and you may also want to collect the restaurant's bank account information for refunds.

Let's see how we can do this with Quickr. First let's break down how we want to onboard the restaurant.

1. Collect the restaurant's information.
2. Sign a contract with the restaurant.
3. Run checks on the restaurant.

const BASE_URL = "https://api.eu.quickr.no/v2/accounts/${ACCOUNT_ID}";
const ACCOUNT_ID = TQ - ACCOUNT - ID - HERE;

// step 1: Authenticate
const token = await getAccessToken(apiKey);

// step 2: Create a case
const response = await fetch(`${BASE_URL}/cases`, {
    method: "POST",
    headers: {
        Authorization: `Bearer ${token}`,
        "Content-Type": "application/json",
    },
    body: JSON.stringify({
        checks: [
            {
                type: "sanction",
            },
            {
                type: "company",
            },
            {
                type: "credit_score",
            },
            {
                type: "bank_account",
            },
            // This check provides with E-Signing functionality
            {
                type: "signatory",
            },
        ],
        sections: [
            {
                type: "company",
            },
            {
                type: "ultimate_beneficial_ownership",
            },
            {
                type: "signatory",
            },
            {
                type: "bank_account",
            },
            {
                type: "product_service",
            },
            {
                type: "agreement",
            },
        ],
        prefills: [
            {
                type: "company",
                data: [
                    {
                        organization_number: "919656395",
                        country: "NO",
                    },
                ],
            },
            // let's add our service here
            {
                type: "product_service",
                data: [
                    {
                        product_id: "delivery_service",
                        name: "Delivery service",
                        description: "Delivery service for restaurants",
                        price: ["1.5% of order value"],
                    },
                ],
            },
            // let's add our agreement here
            {
                type: "agreement",
                data: [
                    {
                        name: "Terms and conditions",
                        url: "https://example.com/terms_and_conditions.pdf",
                    },
                ],
            },
            //
        ],
        // This is the default action, feel free to omit it.
        actions: ["request_declaration"],
    }),
});

Having created the case, in addition to prefilling the data for us, Quickr will also generate the declaration url form which points to hosted form where the restaurant can fill in the information we don't have.

A few thing to note before we move on:

• Customization of the form can be done in the dashboard under settings->branding.
• You will need to send the declaration url to the restaurant.
• A case cannot have more than one declaration url.
• You can partially update the declaration via the API see here.
• Once declaration is completed, you can only partially update the declaration see here. After the nice restaurant owner has filled the form, Quickr will automatically send out emails to whoever needs to sign the contract. Quickr uses BankID for signing and verification of signatories, more on that and how to sign contracts on test here.

Once the contract is signed, Quickr will automatically run the checks on the declared information and the information we already have.(See why I said the case is a folder for your customer?). After a few seconds, the case will be update with the check results and the status will change to READY_FOR_REVIEW. You can now review the results and decide if you want to onboard the restaurant or not via the dashboard.

Note: All the checks will run after the contract is signed.

In some situation you may need to qualify a customer before onboarding them. For example, you may want to know if a customer is a legitimate business before onboarding them. In this section, we will see how to do this with Quickr. Going back to our restaurant example, here's how we can we do this in Quickr?

1. Run some checks on the restaurant.
2. If they pass our criteria, we will send them the declaration url.
3. Collect the restaurant's information.
4. Sign a contract with the restaurant.
5. Run checks on the restaurant.

const BASE_URL = "https://api.eu.quickr.no/v2/accounts/${ACCOUNT_ID}";
const ACCOUNT_ID = TQ - ACCOUNT - ID - HERE;

// step 1: Authenticate
const token = await getAccessToken(apiKey);

// step 2: Create a case
const response = await fetch(`${BASE_URL}/cases`, {
    method: "POST",
    headers: {
        Authorization: `Bearer ${token}`,
        "Content-Type": "application/json",
    },
    body: JSON.stringify({
        checks: [
            {
                type: "sanction",
            },
            {
                type: "company",
            },
            {
                type: "credit_score",
            },
            {
                type: "bank_account",
            },
            // This check provides with E-Signing functionality
            {
                type: "signatory",
            },
        ],
        sections: [
            {
                type: "company",
            },
            {
                type: "ultimate_beneficial_ownership",
            },
            {
                type: "signatory",
            },
            {
                type: "bank_account",
            },
            {
                type: "product_service",
            },
            {
                type: "agreement",
            },
        ],
        prefills: [
            {
                type: "company",
                data: [
                    {
                        organization_number: "919656395",
                        country: "NO",
                    },
                ],
            },
            // let's add our service here
            {
                type: "product_service",
                data: [
                    {
                        product_id: "delivery_service",
                        name: "Delivery service",
                        description: "Delivery service for restaurants",
                        price: ["1.5% of order value"],
                    },
                ],
            },
            // let's add our agreement here
            {
                type: "agreement",
                data: [
                    {
                        name: "Terms and conditions",
                        url: "https://example.com/terms_and_conditions.pdf",
                    },
                ],
            },
            //
        ],
        // This is the default action, feel free to omit it.
        actions: ["perform_checks"],
    }),
});

As you can see here, the only difference is that we swapped the request_declaration action with perform_checks action. This will tell Quickr to just run the checks on data discovered from third party sources and the data we already have. After the checks are done, the case will be updated with the check results and the status will change to READY_FOR_REVIEW. You can now review the results and decide if you want to onboard the restaurant or not.

If you decide to onboard the restaurant, you just need to create the declaration url to collect the restaurant's information. You can do that as follows:

const BASE_URL = "https://api.eu.quickr.no/v2/accounts/${ACCOUNT_ID}";
const ACCOUNT_ID = TQ - ACCOUNT - ID - HERE;

// step 1: Authenticate
const token = await getAccessToken(apiKey);

// step 2: Create a declaration url

const response = await fetch(`${BASE_URL}/cases/${CASE_ID}/declarations`, {
    method: "POST",
    headers: {
        Authorization: `Bearer ${token}`,
        "Content-Type": "application/json",
    },
});

This will generate the declaration url for the case and put the case in FORM_NOT_STARTED status allowing the restaurant owner to fill the form. After the restaurant owner has filled out the form the process is same as before. After the declaration is completed, Quickr will automatically send out emails to whoever needs to sign the contract, then run the checks on the declared information and the information we already have. After a few seconds, the case will be update with the check results and the status will change to READY_FOR_REVIEW.

Note: You can not add more declaration sections after creation for cases with perform_checks action. See here for more information.

Now that we have onboarded the restaurant, we need to keep an eye on them to make sure they remain legitimate business. In this section, we will see how to do this with Quickr. It's actually pretty simple, Quickr does this automatically for you. All you need to do is to add the frequency of the checks you want to run on the case. You can do this as you create the case or update the case later. Let's see how we can modify our initial request to add the frequency of the checks.

For more information on the options available for frequency see here.

const BASE_URL = "https://api.eu.quickr.no/v2/accounts/${ACCOUNT_ID}";
const ACCOUNT_ID = TQ - ACCOUNT - ID - HERE;

// step 1: Authenticate
const token = await getAccessToken(apiKey);

// step 2: Create a case
const response = await fetch(`${BASE_URL}/cases`, {
    method: "POST",
    headers: {
        Authorization: `Bearer ${token}`,
        "Content-Type": "application/json",
    },
    body: JSON.stringify({
        // Add the frequency of the checks here
        checks: [
            {
                type: "sanction",
                options: {
                    schedule: "R-1/P1D",
                },
            },
            {
                type: "company",
                options: {
                    schedule: "R-1/P1M",
                },
            },
            {
                type: "credit_score",
                options: {
                    schedule: "R-1/P1Y",
                },
            },
            {
                type: "bank_account",
            },
            {
                type: "signatory",
            },
        ],
        sections: [
            {
                type: "company",
            },
            {
                type: "ultimate_beneficial_ownership",
            },
            {
                type: "signatory",
            },
            {
                type: "bank_account",
            },
            {
                type: "product_service",
            },
            {
                type: "agreement",
            },
        ],
        prefills: [
            {
                type: "company",
                data: [
                    {
                        organization_number: "919656395",
                        country: "NO",
                    },
                ],
            },
            {
                type: "product_service",
                data: [
                    {
                        product_id: "delivery_service",
                        name: "Delivery service",
                        description: "Delivery service for restaurants",
                        price: ["1.5% of order value"],
                    },
                ],
            },
            {
                type: "agreement",
                data: [
                    {
                        name: "Terms and conditions",
                        url: "https://example.com/terms_and_conditions.pdf",
                    },
                ],
            },
            //
        ],
    }),
});

The other alternative is to the patch case endpoint, see here for more information.

For situations where you want to run a check on a case immediately, say you heard on the news that the restaurant is involved in some shady business and you want to run a check on them immediately. You can do this by calling the schedule checks endpoint. See here for more information. This will run the check immediately and update the case with the results. These checks will not affect the frequency of the checks already scheduled on the case.

With Quickr, you can automate different parts of the onboarding process using automations. For example, you can automate the case approval process by having Quickr automatically approve cases that pass certain criteria.

For our case, we want to approve company cases that pass the following criteria:

• not on any sanction lists.
• has a credit score of 70 or higher.
• Is older than 2 years
• All owners are from the same country as the company.

To do this we need to construct the automation payload as follows:

First things first, let's create the bare bones of the automation. We want this to run this automation when a case is ready to be reviewed.

{
    "name": "Auto approve",
    "description": "Auto approve simple cases",
    "trigger": [
        {
            "type": "case_status_updated",
            "status": "READY_FOR_REVIEW"
        }
    ]
}

Moving on to the conditions we need to be true for the action to run. We'll go through each condition one by one.

• Not on any sanction lists? This means that the sanction check should not have any flags or the sanction check should not be present in the case.

{
    "conditions": [
        {
            // here we use the or condition which will evaluate to true if any of the conditions are true.
            "type": "or",
            "conditions": [
                // if we have sanction check, we don't want to have any flags
                {
                    "type": "equal",
                    "field": "$.checks[?(@.type==='sanctions')].data[0].flags.length",
                    "value": "0"
                },
                // otherwise, we don't want to have a sanction check at all
                {
                    "type": "equal",
                    "field": "$.checks[?(@.type==='sanctions')].data.length",
                    "value": "0"
                }
            ]
        }
    ]
}

• Has a credit score of 70 or higher? This means that the credit_score should have a score of 70 or higher.

{
    // here we use the and condition which will evaluate to true if all the conditions are true.
    "type": "and",
    "conditions": [
        // we should have a credit score check to have a `credit_score` discovery
        {
            "type": "equal",
            "field": "$.checks[?(@.type==='credit_score')].data.length",
            "value": "0"
        },
        // and  the credit score we have should be greater than 70%
        {
            "type": "greater_than_or_equal",
            "field": "$.current_information[?(@.type==='credit_score')].data[*].current_credit_score.value",
            "value": "70"
        }
    ]
}

• Is older than 2 years? This means that the company should have been registered for more than 2 years.

{
    // here we going to use the special `context` field to access the company age
    "type": "greater_than_or_equal",
    "field": "$.context.company_age",
    "value": "2"
}

• All owners are from the same country as the company? This means that the ultimate_beneficial_ownership should have the same country as the company.

{
    // notice that we can compare values already in the case
    "type": "every",
    "field": "$.prefills[?(@.type==='ultimate_beneficial_ownership')].data[*].country",
    "path": "$.prefills[?(@.type==='company')].data[*].country"
}

Putting it all together, we have the automation payload as follows:

{
    "name": "Auto approve",
    "description": "Auto approve simple cases",
    "trigger": [
        {
            "type": "case_status_updated",
            "status": "READY_FOR_REVIEW"
        }
    ],
    "conditions": [
        {
            "type": "or",
            "conditions": [
                {
                    "type": "equal",
                    "field": "$.checks[?(@.type==='sanctions')].data[0].flags.length",
                    "value": "0"
                },
                {
                    "type": "equal",
                    "field": "$.checks[?(@.type==='sanctions')].data.length",
                    "value": "0"
                }
            ]
        },
        {
            "type": "and",
            "conditions": [
                {
                    "type": "equal",
                    "field": "$.checks[?(@.type==='credit_score')].data.length",
                    "value": "0"
                },
                {
                    "type": "greater_than_or_equal",
                    "field": "$.current_information[?(@.type==='credit_score')].data[*].current_credit_score.value",
                    "value": "70"
                }
            ]
        },
        {
            "type": "greater_than_or_equal",
            "field": "$.context.company_age",
            "value": "2"
        },
        {
            "type": "every",
            "field": "$.prefills[?(@.type==='ultimate_beneficial_ownership')].data[*].country",
            "path": "$.prefills[?(@.type==='company')].data[*].country"
        }
    ]
}

Finally we want to tell the automation to actually do something:

"actions": [
  {
    "type": "set_case_status",
    "status": "ACTIVE"
  }
]

Making our final request to create the automation:

const BASE_URL = "https://api.eu.quickr.no/v2/accounts/${ACCOUNT_ID}";
const ACCOUNT_ID = TQ - ACCOUNT - ID - HERE;

// step 1: Authenticate
const token = await getAccessToken(apiKey);

// step 2: Create an automation
const response = await fetch(`${BASE_URL}/automations`, {
    method: "POST",
    headers: {
        Authorization: `Bearer ${token}`,
        "Content-Type": "application/json",
    },
    body: JSON.stringify({
        name: "Auto approve",
        description: "Auto approve simple cases",
        trigger: [
            {
                type: "case_status_updated",
                status: "READY_FOR_REVIEW",
            },
        ],
        conditions: [
            {
                type: "or",
                conditions: [
                    {
                        type: "equal",
                        field: "$.checks[?(@.type==='sanctions')].data[0].flags.length",
                        value: "0",
                    },
                    {
                        type: "equal",
                        field: "$.checks[?(@.type==='sanctions')].data.length",
                        value: "0",
                    },
                ],
            },
            {
                type: "and",
                conditions: [
                    {
                        type: "equal",
                        field: "$.checks[?(@.type==='credit_score')].data.length",
                        value: "0",
                    },
                    {
                        type: "greater_than_or_equal",
                        field: "$.current_information[?(@.type==='credit_score')].data[*].current_credit_score.value",
                        value: "70",
                    },
                ],
            },
            {
                type: "greater_than_or_equal",
                field: "$.context.company_age",
                value: "2",
            },
            {
                type: "every",
                field: "$.prefills[?(@.type==='ultimate_beneficial_ownership')].data[*].country",
                path: "$.prefills[?(@.type==='company')].data[*].country",
            },
        ],
        actions: [
            {
                type: "set_case_status",
                status: "ACTIVE",
            },
        ],
    }),
});

And that's it! You have created your first automation. Let's connect this with a case. When creating the case just add the automations field with the id of the automation you just created. See here for more information.

const response = await fetch(`${BASE_URL}/cases`, {
    method: "POST",
    headers: {
        Authorization: `Bearer ${token}`,
        "Content-Type": "application/json",
    },
    body: JSON.stringify({
        checks: [
            {
                type: "sanction",
            },
            {
                type: "company",
            },
            {
                type: "credit_score",
            },
            {
                type: "bank_account",
            },
            {
                type: "signatory",
            },
        ],
        sections: [
            {
                type: "company",
            },
            {
                type: "ultimate_beneficial_ownership",
            },
            {
                type: "signatory",
            },
            {
                type: "bank_account",
            },
            {
                type: "product_service",
            },
            {
                type: "agreement",
            },
        ],
        prefills: [
            {
                type: "company",
                data: [
                    {
                        organization_number: "919656395",
                        country: "NO",
                    },
                ],
            },
            {
                type: "product_service",
                data: [
                    {
                        product_id: "delivery_service",
                        name: "Delivery service",
                        description: "Delivery service for restaurants",
                        price: ["1.5% of order value"],
                    },
                ],
            },
            {
                type: "agreement",
                data: [
                    {
                        name: "Terms and conditions",
                        url: "https://example.com/terms_and_conditions.pdf",
                    },
                ],
            },
        ],
        actions: ["perform_checks"],
        automations: [
            {
                id: "AUTOMATION_ID",
            },
        ],
    }),
});

Note: The default condition for the automations is and and requires all conditions to be true for the action to run. If a field is not present in the case, the condition will evaluate to false, if you want to check if a field is defined you can use the equal_to_null condition. See here for more information. something

• What happens if the restaurant owner doesn't sign the contract? Quickr will periodically send email reminders to the restaurant owner to sign the contract until it is signed or past a month from the date of creation. You can also renew the contract by calling POST /v2/accounts/{aid}/cases/{cid}/contracts/{contract_id}

• Can I have multiple declaration forms for a case? No, a case can only have one declaration url. If you need to do multiple declarations, you will need to create multiple cases.

• Can I have more than one case with the same organization number or SSN? Yes, you can have multiple cases with the same organization number or SSN. Each case is uniquely identified by a case id.

• Does the customer need to refill the form for ODD(ongoing due diligence) checks? No, the customer only needs to fill the form once. Quickr will automatically run the checks on the declared information and the information we already have.

• Do I need to perform any sort of check to get prefilled information on a case? No, Quickr will automatically populate the prefills with information it finds from public registries and other third party sources.

• I want to perform only X checks for now, but might want to perform Y checks later. How do I do this? You will need to create a new case with the checks you want to perform at that time. Once a case is declared or in some cases created you cannot add or remove checks from it.

• If I archive a case, will the ODD checks still run? No, archiving a case will stop all scheduled checks on the case.

• If I want to fetch new data on a case do I need to create a new case? No, Quickr automatically does ongoing discovery for you so in case of any changes the case status will change to READY_FOR_REVIEW and you can review the changes.

• How do I know which sections I need to perform a check? You can find this information in the checks documentation.

• Do I need to enable signatory check to run a check on a company's board members? No, you only need to add a signatory section to the case. The signatory section will be populated with the company's board members and persons of authority.

• If I include checks that require declaration like bank account in a case with perform_checks action, will these checks be performed/fail? No, these checks will not be performed. Checks will only be performed when the data it requires is available.

• Is there a way to test E-Signature on the test environment? Yes, you can use the test BankID credentials to sign contracts on the test environment. See here for more information.

• Where are the results for previous checks on a case? Due to size limitations, the case will only contain the latest check results. For previous check results, you can use the case events endpoint. See here for more information.

• Where can I find the latest information about a company? The latest information about a company can be found in the current_information field in the case details. See here for more information.

• The customer is not going to declare any information, why do I still need to add sections to the case? The sections are not only used for filling out the form/declaration but also to tell Quickr what kinds of information you want to discover from third party sources. For example, if you want to discover the company's board members, you will need to add a signatory section to the case.

• Can I use the Search company API instead of creating a case to retrieve information on a company? It depends, the search company API is meant to be just that a search API and so the data it provides is limited. If you need more information on a company, you will need to create a case.

• Can I get the full json response as is from the Creditsafe API? Yes, when you create a case with the credit_score check, Quickr will populate the reports with both the pdf and json file links. You can use the json file link to get the full json response as is from the Creditsafe API.See here for more information.

The API is built around RESTful architecture utilizing predictable and resource-oriented URLs. Request bodies and responses are JSON-encoded. Standard HTTP response codes, authentication methods, and verbs are used to maintain consistency and ease of use. Authenticating an API request requires an API key provided by our dashboard, allowing the user to choose between test mode or live mode.

Authentication is done by using a Bearer token, which can be requested by using the API key provided by your dashboard. The token is valid for 1 hour and can be refreshed by requesting a new token.

To request a token, simply send a request to /auth/token with the Authorization header set to Bearer their-api-key. In response, a unique access token will be provided which remains active for one hour.

Note: Please prefix all API requests with v1/accounts/{aid}.

Example request: Requesting access token with API key

POST /auth/token HTTP/1.1
Host: example.com
Authorization: Bearer YOUR_API_KEY_FROM_DASHBOARD

Example response:

HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 123

{
  "access_token": "your_access_token_here",
  "token_type": "Bearer",
  "expires_in": 3600
}

All subsequent requests to the API must include the Bearer access token in the Authorization header.

Example request using the returned access token to list cases:

GET /cases HTTP/1.1
Host: example.com
Authorization: Bearer {access_token}

The API flow is centered around three core components:

• Cases, which represent a unit of work within the system and contain relevant documents and information required for compliance.
• Contracts, which are optional and serve as a formal agreement between customers and their clients or counterparts to comply with KYC and AML requirements.
• Checks, which are the various procedures performed to verify the identity and authenticity of individuals or entities involved with a particular case.

A case is a unit of work for the Quickr API. It contains all the information required to perform a compliance check together with any documents, information, checks, and check results associated with the case.

Creating a case

A case can be created by sending a POST request to the /cases endpoint. The response will contain a unique identifier for the case, which can be used to retrieve the case at a later time.

• Actions: Actions enable you to control the behavior of the case. Currently, the following actions are supported:

  • request_declaration : This is the default action. With this action the case will be created with a declaration form that needs to be completed before the checks can be performed on the case.

  • perform_checks : This action will trigger the checks to be performed on the case immediately after the case is created. Without the need for a declaration form to be completed. Declarations can be added to the case at a later time.

• Prefills: Prefills in Quickr enable you to pre-populate information into the declaration form to simplify and speed up the declaration process. You can use this feature to provide information you already have about the entity or include custom information. By providing the company prefill's organization_number and country fields, Quickr can automatically fill out the related company, signatory, and ultimate_beneficial_owner prefills on your behalf.

Example request:

{
"publisher": {
  "name": "Your company name",
  "support_email": "support@company.com"
},
"prefills": [
  {
    "type": "company",
    "data": [
      {
        "organization_number": "919656395",
        "country": "NO"
      }
    ]
  }
],
"sections": [
  {
    "type": "company"
  },
  {
    "type": "ultimate_beneficial_ownership"
  },
  {
    "type": "signatory"
  }
]
}

• sections : These are the sections that will be shown in the declaration form. You can choose which sections you want to show in the form.

• checks : These are the checks that will be performed on the case. Note that some checks may require specific information to be provided in the case. For example signatory check requires signatory section to be present in the case.

  Available checks:

  • company : Checks a company's information provided in the declarations against the company's in the prefills section and the company status from information in the public register as well as against sanction lists.

  • signatory : Checks a signatory's information provided in the declarations against the signatory's information in the prefills section, and the received after the signatory has signed a contract.

  • individual : Checks an individual information provided in the declarations against the individual's information received after the individual has verified their identity

  • ultimate_beneficial_ownership : Checks a ultimate beneficial owner's information provided in the declarations against the ultimate beneficial owner's information in the prefills section,

  • sanctions : Checks the company , signatory and ultimate_beneficial_ownership information against the sanction and criminal lists.

  • politically_exposed_person : Checks the company , signatory and ultimate_beneficial_ownership information against the politically exposed persons lists.

  • bank_account : Requires bank_account section to be present in the case. Checks the validity of the bank account and if the entity is the owner of the bank account.

  • credit_score : Requires company section to be present in the case. Checks the credit score of the company. Also populates the discoveries field with the credit score information.

  • agreement : Requires agreement section to be present in the case. Checks if the user accepted custom agreements passed in the agreements prefill.

  Note: If a case is created with only credit_score check and prefills, the case will automatically be completed with the credit_score check result.

Case lifecycle

A case can follow one of the following life cycles:

Case with signing requirement

  sequenceDiagram
      autonumber
      participant User
      participant QuickrApi
      User->>QuickrApi: POST /cases/
      QuickrApi-->>User: Return case with `declaration_url`
      alt intent "declarations_update"
      User->>QuickrApi: PUT /cases/:cid/declarations/:did
      QuickrApi-->>User: Update result
      else intent "declarations_finished"
      User->>QuickrApi: PUT /cases/:cid/declarations/:did
      QuickrApi-->>User: Update result
      end
      User->>QuickrApi: GET cases/:cid/contracts/:contract_id/signatories/:sid/sign
      QuickrApi->>QuickrApi: Process checks asynchronously
      QuickrApi-->>User: Results available upon query
    

Case without signing requirement

  sequenceDiagram
      autonumber
      participant User
      participant QuickrApi
      User->>QuickrApi: POST /cases/
      QuickrApi-->>User: Return case with `declaration_url`
      alt intent "declarations_update"
      User->>QuickrApi: PUT /cases/:cid/declarations/:did
      QuickrApi-->>User: Update result
      else intent "declarations_finished"
      User->>QuickrApi: PUT /cases/:cid/declarations/:did
      QuickrApi-->>User: Update result
      end
      QuickrApi->>QuickrApi: Process checks asynchronously
      QuickrApi-->>User: Results available upon query
    

Case with credit_score check only

  sequenceDiagram
      autonumber
      participant User
      participant QuickrApi
      User->>QuickrApi: POST /cases/
      QuickrApi-->>User: Return case
      QuickrApi->>QuickrApi: Process checks asynchronously
      QuickrApi-->>User: Results available upon query
    

Contracts are agreements between a customer and their customer, detailing the terms and conditions of their business relationship. These are automatically generated by Quickr (for any case with a signatory check) in PDF form based on the sections included in the case after the form declaration is complete and once signed by your customer they're cryptographically encrypted and are available for download via the API or the dashboard. Contracts are digitally signed via BankID.

Your customer(s) will receive an initial email with the link and instructions to sign the contract and follow-up emails until the contract is signed within the first month of the contract being created. All the emails and some aspects of the contract can be customized within the dashboard under settings->branding.

Quickr also periodically sends email reminders to your customers to sign the contract until it is signed or past a month from the date of creation.

Some things to note about contracts:

• A contract is only generated for a case requiring signing i.e a case with a signatory check.
• The contract will be in the language that the form was filled in. Currently, Quickr supports Norwegian and English.
• Once signatories have been selected, the contract will remain in a pending state until all signatories have signed the contract.
• A contract will be available for signing for 85 days after the case declaration has been completed. If the contract is not signed within this time, you can renew it by calling POST /v2/accounts/{aid}/cases/{cid}/contracts/{contract_id}

Signing a contract on test environment

Quickr utilizes BankID for signing and verification of signatories. Signing in test mode requires a test BankID for the relevant country. Generating a test BankID is easy and can be done by following the steps below:

Norway

Go to https://ra-preprod.bankidnorge.no/#/search/endUser and follow the steps below to generate a test BankID.

1. Navigate to the "Test number generator" tab and click "Generate number" with the default settings.
2. With the "Netcentric" tab selected input the first, last and BankID friendly name, if possible the names should match your case signatory
3. Click "Order" and test BankID will be generated.

   Note: For test BankID the OTP is always otp and the password is qwer1234.

Sweden

Sweden BankID has a straightforward process documented on their site.

You can then use the generated test BankID to sign contracts on test accounts.

Denmark

1. Go to https://pp.mitid.dk/test-tool/frontend and this will allow you to generate a test BankID.

2. Download the MitID app from the App Store or Google Play and use the test BankID to sign contracts on test accounts.

3. You can the use the generated test BankID to sign contracts on test accounts.

Finland

Finland BankID supports different testing credentials depending on the bank being used.

Aktia

• Username(Käyttäjätunnus): 12345678
• Password(Salasana): 123456
• Security number(Turvaluku): 1234
• Security number(Turvaluku) 2: 1234

Handelsbanken

• Username(Käyttäjätunnus): 11111111
• Password(Salasana): 123456
• Security number(Turvaluku): 123456
• Security number(Turvaluku) 2: 123456

LähiTapiola

• Username(Käyttäjätunnus): 12345678
• Password(Salasana): any numbers
• code (Tunnusluku): any four numbers
• code (Tunnusluku) 2: any four numbers

Nordea

• Tunnus: 123456
• Password(Salasana): 1234
• Verification code (Vahvistustunnus): any four numbers

​OP / Osuuspankki

• Username(Käyttäjätunnus): 123456
• Password(Salasana): 7890
• Key number (Avainluku): any four numbers

POP Bank

• Username(Käyttäjätunnus): 11111111
• Password(Salasana): 123456
• Security number(Turvaluku): 123456
• Security number(Turvaluku) 2: 123456

S-Bank

• Username(Käyttäjätunnus): 12345678
• Password(Salasana): any numbers
• code (Tunnusluku): any four numbers
• code (Tunnusluku) 2: any four numbers

Savings bank

• Username(Käyttäjätunnus): 11111111
• Password(Salasana): 123456
• Security number(Turvaluku): 123456
• Security number(Turvaluku) 2: 123456

Ålandsbanken

• Username(Käyttäjätunnus): 12345678
• Password(Salasana): any numbers
• code (Tunnusluku): any four numbers
• code (Tunnusluku) 2: any four numbers

Oma Säästöpankki

• Username(Käyttäjätunnus): 11111111 / 22222222
• Password(Salasana): 123456
• Security number(Turvaluku): 123456
• Security number(Turvaluku) 2: 123456

Checks allow you to perform different action based on the information discovered or declared in a case. Quickr supports a variety of checks that can be performed on a case. Checks are performed on the data discovered from the public register and the data provided in the declaration form. The checks are performed asynchronously and the results are available upon querying the case.

Checks states

A check can be in one of the following states:

• NOT_STARTED : The check has not been started. When in this state, the check is waiting for the declaration form to be completed.
• IN_PROGRESS : The check is currently being performed.
• COMPLETED : The check has been completed.
• FAILED : Quickr was unable to perform the check.

stateDiagram-v2
    [*] --> NOT_STARTED
    NOT_STARTED --> IN_PROGRESS
    IN_PROGRESS --> COMPLETED
    IN_PROGRESS --> FAILED
      state COMPLETED {
        [*] --> WITH_FLAGS
        WITH_FLAGS --> [*]
        [*] --> WITHOUT_FLAGS
        WITHOUT_FLAGS-->[*]
    }
    COMPLETED --> [*]
    FAILED --> [*]

Check scheduling

Quickr supports scheduling of checks for Ongoing Due Diligence (ODD) and Know Your Customer (KYC) processes. Checks can be scheduled to run at a specific repeating predefined interval. Currently, the following intervals are supported: R-1/P1D(Daily), R-1/P1M(Monthly) and R-1/P1Y(Yearly) intervals. The initial check intervals are determined from when the check initially runs see above. The interval is set per check type by using the schedule field in the check object. The schedule field is a string that contains the interval in ISO 8601 format.

For example adding a daily PEP check to our previous example the request would look like this:

POST /cases
Authorization: Bearer <token>

{
    "publisher": {
        "name": "Your company name",
        "support_email": "support@company.com"
    },
    "prefills": [
        {
            "type": "company",
            "data": [
                {
                    "organization_number": "919656395",
                    "country": "NO"
                }
            ]
        }
    ],
    "sections": [
        {
            "type": "company"
        },
        {
            "type": "ultimate_beneficial_ownership"
        },
        {
            "type": "signatory"
        }
    ],
    "checks": [
        {
            "type": "politically_exposed_person",
            "options": {
                "schedule": "R-1/P1D"
            }
        }
    ]
}

For all checks after the initial check has run, Quickr will also get updates on the case from public registries and other third party sources to ensure that the case is up to date, before running the check. You will receive a notification(s) when the check has been completed which will contain the results of the check and updates to the case if any. Notifications are sent via webhook if your case has a callback_url set. The notification will be sent when the checks are completed and contains changes(if any) from the check results since the last check. More information on this can be found in the Case Events section.

Adding a callback url to our previous example the request would look like this:

POST /cases
Authorization: Bearer <token>

{
    "publisher": {
        "name": "Your company name",
        "support_email": "support@company.com"
    },
    "prefills": [
        {
            "type": "company",
            "data": [
                {
                    "organization_number": "919656395",
                    "country": "NO"
                }
            ]
        }
    ],
    "sections": [
        {
            "type": "company"
        },
        {
            "type": "ultimate_beneficial_ownership"
        },
        {
            "type": "signatory"
        }
    ],
    "checks": [
        {
            "type": "politically_exposed_person",
            "options": {
                "schedule": "R-1/P1D"
            }
        }
    ],
    "urls": {
        "callback_url": "https://yourdomain.com/callback"
    }
}

Running checks on-demand

Checks can be run on-demand by calling the schedule checks endpoint. This will run the check immediately and update the case with the results. These checks will not affect the frequency of the checks already scheduled on the case. See here for more information.

POST /cases/:cid/schedule_checks
Authorization

{
    "checks": [
        {
            "type": "company"
        }
    ]
}

Check results

Check results can be found in the checks field of the case by querying the cases/:cid endpoint. The checks field contains an array of check results one for each check performed on the case. The flags field contains an array of flags that were found during the check. The discoveries field contains an array of discoveries that were found during the check.

Available flags codes:

Some common flag codes are:

• DECLARATION_MISSING : Which indicates that the declaration is missing.
• PREFILL_MISSING : Which indicates that the required prefill is missing.
• DATA_MISSING: Which indicates that required data is missing.
• DATA_MISMATCH: Which indicates that the data provided in the declaration does not match the data in the prefill.
• DATA_MANUAL_UPDATE: Which indicates the data provided in the declaration has been manually updated from the prefill.
• DISCOVERY_MISSING: Which means Quickr was unable to find entity/persons information in the public register/data source.
• THIRD_PARTY_ERROR: Which means Quickr was unable to get information from the third party source.
• INTERNAL_SERVER_ERROR: Which means Quickr encountered an internal error while performing the check.

Some check specific flag codes are:

• company : A company check may contain the following flag types:

  • COMPANY_INACTIVE : Which indicates that the company is inactive from the public register.
  • COMPANY_IN_SANCTIONS : Which indicates that the company is in the sanction list.
  • PARENT_COMPANY_CHANGED : Specific to subunit companies which indicates that the parent company has changed.

• signatory : A signatory check may contain the following flag types:

  • CONTRACT_NOT_SIGNED : This means that the contract has not completed the signing process.
  • SIGNATORY_MISMATCH : This means that the signatory information provided in the declaration does not match the signatory information from the signed contract information.

• ultimate_beneficial_ownership : A ultimate beneficial ownership check may contain the following flag types:

  • PERSON_IN_SANCTIONS : Which indicates that the person is in the sanction list.
  • PERSON_IN_PEP : Which indicates that the person is/is affiliated with a politically exposed person.
  • COMPANY_TYPE_NOT_SUPPORTED : Which indicates that Quickr does not support this check for the company type. In most cases this means that the company type is a sole proprietorship.
  • POSSIBLE_FAMILY_RELATIONS: Which indicates some possible family relations between the ultimate beneficial owners.
  • DATA_MANUALLY_ADDED: Which indicates that the data added was not found in the public register.

• politically_exposed_person : A politically exposed person check may contain the following flag types:

  • PERSON_IN_PEP : Which indicates that the person is/is affiliated with a politically exposed person.

• sanctions : A sanctions check may contain the following flag types:

  • COMPANY_IN_SANCTIONS : Which indicates that the company is in the sanction list.
  • PERSON_IN_SANCTIONS : Which indicates that the person is in the sanction list.

• bank_account : A bank account check may contain the following flag types:

  • BANK_ACCOUNT_NUMBER_INVALID : Which indicates that the bank account is invalid/is not owned by the entity.
  • BANK_ACCOUNT_NUMBER_UNSUPPORTED : Which indicates that Quickr cannot verify the bank account number. Currently only Norwegian bank account numbers are supported.

• credit_score : A credit score check may contain the following flag types:

  • COMPANY_HAS_HIGH_RISK : Which indicates that the credit score is lower than Quickr's set threshold, which is 30%.
  • COMPANY_HAS_PAYMENT_REMARKS : Which indicates that the company has some negative payment remarks.
  • COMPANY_TYPE_NOT_SUPPORTED : Which indicates that Quickr does not support this check for the company type. In most cases this means that the company type is a sole proprietorship.
  • CASE_TYPE_NOT_SUPPORTED : Which indicates that Quickr does not support this check for the case type. Only happens when in sandbox mode while using data not in the test sandbox.

• agreement : An agreement check may contain the following flag types:

  • AGREEMENT_NOT_ACCEPTED : Which indicates that the user has not accepted the agreement.

• website : A website check may contain the following flags:

  • MERCHANT_CATEGORY_CODE_UPDATED: Which indicates that the merchant category code has been updated, from the previously declared value.

  • TRAFFIC_UPDATED: Which indicates that the website traffic has changed, where available details will be provided in the details field.

  • INVALID_URL: Which indicates that the website URL is invalid.

  • TOO_MANY_REDIRECTS: Which indicates that the website has too many redirects.Currently Quickr only supports 3 redirects.

  • WEBSITE_UNREACHABLE: Which indicates that the website is unreachable.

  • REDIRECTED: Which indicates that the website has been redirected to another website.

  • OTHER: Which contains other miscellaneous changes on the website. Eg. Change in the website's technology stack, technology stack version, etc.

Note: Some checks flags records may contain a records field which contains an array of records that caused the flag to be raised. For example, the sanctions check flags record may contain a records field that caused the PERSON_IN_SANCTIONS flag to be raised.

Automations allow you to perform certain actions based off some predefined triggers(Currently we support only one trigger case_status_change). You can create an automation by sending a POST request to the /automations endpoint. The response will contain a unique identifier for the automation, which can be used to retrieve the automation at a later time. Automations utilizes jsonpath to allow you to specify values within the case details data alongside with this you also get access to a context object which contains data that is computed on the fly based off the case details data.

A case can be linked to multiple automations at any time, the order in which the automations are run is not guaranteed. When an automation completes or performs an action on a case, a note will always be added to the case detailing the result and the action performed.

How do I create my automation?see here

To confirm that your integration is working as expected, you can simulate different scenarios by using the following test data.

Note: The test scenarios are only available on the test environment.i.e Accounts starting with TQXXXXXXX.

Company

• Companies with good standing

  Organization number	Country	Name	Status	Board members	Type	Sanction	Credit score
  987654321	NO	Ragnarok AS	Active	3	AS	✗	A
  123456789	NO	Floki Shipbuilders	Active	1	ENK/Sole proprietorship	✗	B

• Companies with bad standing and in sanctions list

  Organization number	Country	Name	Status	Board members	Type	Sanction	Credit score
  987123654	NO	Ecbert Holdings AS	Bankrupt	3	AS	✓	C
  159753468	NO	ROLLO THE WARRIOR	InActive	1	ENK/Sole proprietorship	✓	E

  To use the test data you can pass the organization number and country in the prefills section of the case.

  {
      "type": "company",
      "data": [
          {
              "organization_number": "987654321",
              "country": "NO"
          }
      ]
  }
  

Board members

• Board members for companies with good standing:

  Organization number	Name	Birth date	Title	PEP	Sanction
  987654321	Ragnar Lothbrok	1980-01-01	CEO	✗	✗
  987654321	Lagertha Shieldmaiden	1982-04-15	Chairperson	✗	✗
  987654321	Bjorn Ironside	1960-07-25	Board member	✗	✗
  123456789	Floki Vilgerdarson	1982-01-01	CEO	✗	✗

• Board members for companies with bad standing:

  Organization number	Name	Birth date	Title	PEP	Sanction
  987123654	Ecbert Sigurdson	1980-01-01	CEO	✓	✗
  987123654	Aethelwulf Sigurdson	1982-04-15	Chairperson	✓	✓
  987123654	Aethelred Sigurdson	1960-07-25	Board member	✗	✓
  159753468	Rollo Lothbrok	1979-01-01	CEO	✗	✓

  As illustrated above, when politically_exposed_person, and/or sanctions checks are performed on a case, the check will flag them as PEP and/or Sanction respectively.

Ultimate beneficial owners

• Ultimate beneficial owners for companies with good standing:

  Organization number	Name	Birth date	Title	PEP	Sanction
  987654321	Ragnar Lothbrok	1980	CEO	✗	✗
  987654321	Lagertha Shieldmaiden	1982	Chairperson	✗	✗
  123456789	-	-	-	-	-

• Ultimate beneficial owners for companies with bad standing:

  Organization number	Name	Birth date	Title	PEP	Sanction
  987123654	Ecbert Sigurdson	1980-01-01	CEO	✓	✗
  987123654	Aethelwulf Sigurdson	1982-04-15	Chairperson	✓	✓
  159753468	-	-	-	-	-

  Note: These values will always come prefilled if relevant sections as selected.

Data you can use during declaration

After the case has been created, you can use the following data to fill out the declaration form for the relevant sections.

• Bank Account: For the bank_account check to return a successful result, you can use the following bank account numbers:

  Country	Bank account number
  NO	24681357902
  NO	13579246801
  NO	12345678901
  NO	98765432101

  Any other bank account number will return a failed check result.

• Persons Information: This data can be used to fill out the signatory and ultimate_beneficial_ownership sections.

  Name	Birth date	Title	PEP	Sanction
  Ivar Ragnarsson	1990-02-10	CEO	✓	✓
  Ubbe Ragnarsson	1992-04-15	Chairperson	✓	✗
  Hvitserk Ragnarsson	1995-07-25	Board member	✗	✓

Test Websites(for website check)

To test the website check you can use the following websites:

Website URL	Flags	redirect URL
https://traffic-update.test	TRAFFIC_UPDATED
https://mcc-update.test	MERCHANT_CATEGORY_CODE_UPDATED
https://too-many-redirects.test	TOO_MANY_REDIRECTS	https://too-many-redirects.test/redirect1, https://too-many-redirects.test/redirect2, https://too-many-redirects.test/redirect3
https://website-unreachable.test	WEBSITE_UNREACHABLE
https://redirected.test	REDIRECTED	https://another-site.test/

The token endpoint is used to get the JWT (JSON Web Token) that must be passed in every API request in the Authorization header.

• The access token is valid for 1 hour

As an partner you can create additional Quickr customer accounts associated with you partner account.

You must use separate Quickr accounts for customers that operate independently from one another. When you activate a new account, it is subject to Quickr's standard policies and pricing.