Customers overview

"Identities" are now "Customers"

We used to refer to the representation of your customer in the Weavr system as an identity. We now just call them a customer. The two mean the same thing — you may still see identity in some API fields and older pages.

A customer in the Weavr platform is the verified representation of one of the people or businesses who use the financial services you offer within your application. A corporate represents a business entity, while a consumer represents an individual person.

Corporates

Onboard business entities and verify them with KYB, including UBO and director checks.

Onboard a corporate→

Consumers

Onboard individuals and verify them with KYC, including identity and address checks.

Onboard a consumer→

Customers and your app's users

Your app has its own user accounts and its own login. A customer in the Weavr platform does not replace them. Each person who uses financial features is represented in two linked places:

• In your app - the account your customer signs in to, which you build and control.
• On Weavr - a user of a customer, which holds the regulated accounts, cards, and payment permissions.

You link one of your app's users to one Weavr user. A corporate user can act for one or more corporate customers, using the same credentials for each. Your app remains the system of record for who your users are; Weavr is the system of record for which customers they can act for and what they're allowed to do with money.

Why a separate customer exists

Weavr is the regulated institution behind your financial features. Strong Customer Authentication (SCASCA (Strong Customer Authentication). Strong Customer Authentication - a two-factor authentication solution required by PSD2 regulations for when end-users are accessing their payment account sensitive information or initiating transactions. SCA requires at least two of the following: something you know (password), something you have (device), or something you are (biometrics).) under PSD2 requires the regulated institution to authenticate the end user directly for payment operations, and this obligation can't be delegated to your app. The customer carries that authentication, along with the due diligence - KYCKYC (Know Your Customer). Know Your Customer - the identity verification process for consumer customers. This process allows you to securely verify your user's identity. Weavr asks users to submit the information and documentation they need for approval by financial providers. or KYBKYB (Know Your Business). Know Your Business - the identity verification process for corporate customers. This process allows you to securely verify your business customer's identity. Weavr asks users to submit the information and documentation they need for approval by financial providers. - that regulation ties to it. For the regulatory detail, see PSD2 and Strong Customer Authentication.

Your customer should never see a second account

A customer in the Weavr platform is a backend concept, and the Weavr credential doesn't have to be part of your app's sign-up flow. You can create the user within Weavr and have them set this credential the first time the customer reaches a financial feature. Your customer should still experience one seamless app:

• Collect the Weavr password once, through our secure UI components, rendered inside your own screens with your own branding.
• Present it under your own wording - a backup key or card key for their card or account, not a second "password" or "login" - because to the customer it's a security key, not another account.
• Never show a Weavr-branded login screen or redirect customers to a Weavr URL to authenticate.
• Trigger step-up authentication in place, inside your app, when a sensitive operation requires it.

A visible second login is an integration mistake, not a requirement of the model.

Due diligence

You need to onboard your customers onto Weavr before they can use any financial services.

You can embed a verification process. For consumersConsumers (Consumer). Individual people who can be onboarded as customers on Weavr. Consumer customers require Know Your Customer (KYC) verification. For consumers, the card owner and card assignee are typically the same person., it's called Know Your Customer (KYCKYC (Know Your Customer). Know Your Customer - the identity verification process for consumer customers. This process allows you to securely verify your user's identity. Weavr asks users to submit the information and documentation they need for approval by financial providers.), and for corporatesCorporates (Corporate Identity). Business entities that can be onboarded as customers on Weavr. Corporate customers represent companies and require Know Your Business (KYB) verification. They can have multiple authorised users and issue cards to card assignees., it's Know Your Business (KYBKYB (Know Your Business). Know Your Business - the identity verification process for corporate customers. This process allows you to securely verify your business customer's identity. Weavr asks users to submit the information and documentation they need for approval by financial providers.). This process verifies your user's identity securely, and it takes only a few lines of code on your end. We ask your users to submit the information and documentation we need so that our financial providers can approve them.

Supported countries

We support onboarding corporatesCorporates (Corporate Identity). Business entities that can be onboarded as customers on Weavr. Corporate customers represent companies and require Know Your Business (KYB) verification. They can have multiple authorised users and issue cards to card assignees. and consumersConsumers (Consumer). Individual people who can be onboarded as customers on Weavr. Consumer customers require Know Your Customer (KYC) verification. For consumers, the card owner and card assignee are typically the same person. residing in the following countries:

Austria	Belgium	Bulgaria	Croatia
Cyprus	Czech Republic	Denmark	Estonia
Finland	France	Germany	Greece
Hungary	Iceland	Ireland	Italy
Latvia	Liechtenstein	Lithuania	Luxembourg
Malta	Netherlands	Norway	Poland
Portugal	Romania	Slovakia	Slovenia
Spain	Sweden	United Kingdom

Users

A customer is operated by one or more users, and one corporate user can operate more than one corporate customer. Every user authenticates against the Weavr API and SDKs with one set of credentials, then acts on a selected customer's behalf, subject to the roles assigned to them for that customer.

The first user is special. Every customer is created together with a root userRoot userThe individual who creates the customer. For corporates, the root user needs to be a legal representative of the company, such as a director or someone with power of attorney. For consumers, the root user is the customer. Every customer must always have one root user.: the individual who registered the customer, and who Weavr holds accountable for it. The root userRoot userThe individual who creates the customer. For corporates, the root user needs to be a legal representative of the company, such as a director or someone with power of attorney. For consumers, the root user is the customer. Every customer must always have one root user.:

• For a corporate, must be a legal representative of the company - a director or someone with power of attorney.
• For a consumer, is the consumer themselves.
• Is always assigned the Admin role, and this role can't be removed.

You can optionally invite additional users to a customer at any time. These are typically referred to as authorized usersAuthorized UserAn individual that has been invited by the root user to manage a customer's instruments and transactions. They are not the legal owner of the customer but can be granted access to perform operations on its behalf. For corporates, card assignees are created as Authorized Users. US-English variant of _Authorised User_. - the same kind of user as the root userRoot userThe individual who creates the customer. For corporates, the root user needs to be a legal representative of the company, such as a director or someone with power of attorney. For consumers, the root user is the customer. Every customer must always have one root user., just invited later and not bound to the Admin role. See Invite additional users for the flow.

Roles

We provide a set of pre-configured roles that can be assigned to authorized usersAuthorized UserAn individual that has been invited by the root user to manage a customer's instruments and transactions. They are not the legal owner of the customer but can be granted access to perform operations on its behalf. For corporates, card assignees are created as Authorized Users. US-English variant of _Authorised User_. to control their level of access. The available roles are:

• Card AssigneeCard AssigneeThe person that a card is assigned to and who will use the card. For consumers, the card owner and card assignee are the same person. For corporates, the card assignee and card owner are different entities - the corporate is the card owner and the person using the card is the card assignee. Card assignees must be created as Authorised Users. -- for users who need to access and spend on their own assigned card only.
• Cards Management Role -- for users responsible for managing a card program.
• Funds Management Role -- for users who need to manage fund inflows or outflows.
• Access Management Role -- for users responsible for creating and managing other users.
• Admin -- full access to all operations, combining all of the preceding roles.

Multiple roles can be assigned to a single user, and the root userRoot userThe individual who creates the customer. For corporates, the root user needs to be a legal representative of the company, such as a director or someone with power of attorney. For consumers, the root user is the customer. Every customer must always have one root user. always has the Admin role. Read the user roles page for detailed permissions per role.

Role-based access control is optional

Role-based access control is an optional feature. If you prefer to manage access restrictions within your own system, users can be granted full access via the Admin role.