Definition

User represents the business you want to pay. It's the equivalent of a seller, the beneficiary of a payment. You need to create a User before requesting a Loan. Users don't have an Aria account: it's your responsibility to create and update them.

According to use cases, a User can be :

• A freelancer
• A supplier
• A seller

A User will always be the business company that benefits from an invoice payment.

Choosing the company identifier

When you create a User, we use its company identifier to look the company up in official business registries. When we find it, we retrieve the company details and its legal representatives automatically. Your User then opens the requirement portal with this information already filled in, and has less to provide.

The lookup does not work with every identifier. For example, use:

• France: SIREN (siren)
• Belgium: BCE/KBO number (cben)

Check Supported countries and filter on Users to see the recommended identifier for each country.

📘

Every identifier listed on Supported countries is accepted. With a different identifier, or in a country with no recommended identifier, your User may have to enter their company and legal representative details by hand.

Terms of Service

Your Users (beneficiaries) must accept our Terms of Service when they are the invoice owner before a Loan is created. You have two options:

1. Use our User Contract feature to send the Terms of Service directly to the User for their signature.
2. Obtain the User’s consent to our Terms of Service on your platform, then create a tosAcceptance using our API (or the upcoming dashboard version). Use this URL {url} to display the Terms of Service to your Users, as each consent will be dated and stored. This ensures we can track the exact version of the Terms that each User agreed to.

In some cases, we may require you to use the first method.

Please note: Creating a loan for an invoice-owning User without this consent will result in a loan refusal.

User Contract

The User Contract is the first method described above: Aria sends its Terms of Service to the User for electronic signature. You trigger it through the API, and the current state is always exposed on the User's contractStatus field.

Contract statuses

contractStatus tells you where the User stands in the signature flow:

• notSent: no contract has been sent to the User yet.
• pending: the contract has been sent and is waiting for the User's signature.
• completed: the User has signed and the contract is fully executed.
• voided: the contract was cancelled and is no longer valid. A new one has to be sent.

Sending a contract

Use Send user contract (POST /companies/{companyId}/user/USERID/contract) to create a contract and send it to the User for signature. The User receives an email with the signature request, and contractStatus moves to pending.

Send it when the User has no contract yet, or when the previous one is voided or was never sent. In each of these cases a fresh contract is created.

Resending a contract

If the User did not receive or lost the original email, use Resend user contract (POST /companies/{companyId}/user/USERID/contract/resend) to send the signature request again. This resends the exact same contract, so no new contract is created.

📘

Resend only works while the contract is pending. A completed contract cannot be resent, and a voided or never-sent contract has to go through Send user contract, which issues a new one.

Identity check

KYC procedures have been set up to manage AML/CFT risks since Aria provides financing.

Before paying a user, you have to provide information that you can find in our API Reference. All information is mandatory to fully identify the beneficiary.

We may require proof of identity from the company's legal representative.

KYC docs verification is performed within a 24-hour time frame, from Monday to Friday (Paris Time Zone).

We provide 3 statuses:

• PENDING: The KYC doc is not yet verified.
• VALID: The KYC doc is valid.
• INVALID: The KYC doc is invalid.

📘

We will help you set up your KYC process during your onboarding phase.

Repayment accounts

A User repayment account gives each User its own IBAN. Without them, debtors would have to repay on your company repayment account, making reconciliation harder. Every repayment is traced to the User, and Aria enforces reconciliation with that User's loans (see Repayments per User).

Creating a repayment destination

Use Create a User repayment destination to create the account and choose its currency and country. You can only create repayment destinations for the currencies available to your account. A User has one repayment destination per currency and country: creating it again returns the existing one. The country code shows in the account details the debtors see. For example, a French IBAN starts with the country code FR: FR76 3000 4129 9712 0005 4641 176.

Sharing the account details

List a User's accounts with List a User repayment destinations and add their details to the User's invoices, so that debtors repay there.

🚧

When a User is expected to have a repayment destination, the IBAN on its invoices must be one of the User's repayment destinations. If the IBAN on an invoice does not belong to the User, the Loan for that invoice may be refused.

Strong Customer Authentication

Before Aria can send money out of a User's repayment account, the User's legal representative must complete Strong Customer Authentication on the portal. Aria tracks this with an SCA_ENROLLMENT requirement. See SCA enrollment.