High Risk Support Actions
High Risk Actions
There are a few actions Unit may allow the client's support team to perform, that are considered high-risk.
Risks
When an agent executes an action on behalf of an end customer in order to support them, there are 3 risks that need to be managed:
- The agent's details leaked, and the person with access to the dashboard isn't the agent.
- The agent is a bad actor and is defrauding you or your end customer
- The person calling in for support is not the end customer, but a fraudsted.
Especially when executing high-risk actions, it is extremely important to be highly aware of all 3 risks and mitigate them to the extent possible.
Risk Mitigation Measures
Unit highly recommennds the following for all sensitive actions (list below). This is currently a recommendation, but we reserve the right to change it into a requirement with sufficient advance notice:
Secure Sign In
- IP allow-listing
- SAML
- Multi factor authentication
- Restrict access to the "Admin" role to the smallest group of employees possible (protects against risk #1)
Customer Identity Verification
Before executing high risk actions on behalf of an end customer, you must verify their identity. You must execute at least 2 out of the following steps to authenticate the client:
- OTP - strongly preferred as one of the two verification steps
- Selfie verification
- Identity questions: a. Last 4 digits of the SSN / passport b. Last 4 digits of a card number
- Activity questions ("out of wallet questions") - the customer must provide details of 2 financial actions taken recently (activity type, amount, date)
High Risk Customer Information Updates
Updating a Customer's Phone Number
The phone number serves as the main authentication method for end customers on Unit and as such is highly sensitive.
Best Practices:
- Only Admin users have access to edit a customer's phone number
- It is highly recommended to implement secure sign in
- It is required that you take the customer through customer identity verification.
- If the customer does not have access to their phone number, it is recommended to use as many of the identity verification methods above as possible.
Updating a Customer's Address
The customer address is typically (for consumer use cases) the address that physical cards are shipped to. If the agent is a bad actor, or if they are contacted by a fraudster pretending to be the customer, and they change the address to anything they wish, this may result in a bad actor gaining access to a card.
Best Practices:
- Only Admin users have access to update the customer's address.
- It is highly recommended to implement secure sign in
- It is required that you take the customer through customer identity verification.
- The customer should provide a document confirming the new address - it may be a utility bill, bank statement, lease agreement or current pay stub.
High Risk Card Related Actions
Best Practices:
- Only Admin users have access to sensitive card actions.
- It is highly recommended to implement secure sign in
- It is required that you take the customer through customer identity verification.
- If the customer asks for the card to be shipped to a different address from the one that was provided during their onboarding, verify the new address using a utility bill, bank statement, lease agreement or current pay stub.
Card Actions That Create Financial Risk
There are some card actions that might, if you choose to support them, be abused by bad actors. Some Unit clients, subject to bank approval, choose to allow their support team to perform them anyway in order to provide their customers with a better more seamless experience, exposing themselves to potential losses.
In order to gain access to the features below, Unit would require a formal email, confirming that you acknowledge the financial risk, and choose to take it on, as well as an explicit bank approval.
Reactivating a Card in "SuspectedFraud" Status
Cards may be marked as SuspectedFraud due to unusual or suspicious activity. The cardholder will be contacted via text, email or phone to confirm if the activity was legitimate. If they contact your team before 24 hours have passed from the time the activity was detected, it is highly recommended you ask them to respond to the communication which will reactivate their card.
If it's been 24 hours and the customer still haven't responded, they must contact your support team to reactivate their card.
You may create a support ticket for the Unit team, to look into the activity and re-activate the card.
However, if you choose to review the activity and reactivate the card on your own, you will be able to do it using the Unit dashboard.
By reactivating a card, you are confirming that the end customer is not a fraudster and all the activity done on their card is valid. You are waving your right to contest any disputes filed on transactions that happened prior to reactivating the card.
Best Practices:
- Only Admin users have access to reactivate the card
- It is highly recommended to implement secure sign in
- It is required that you take the customer through customer identity verification.
- Review the end customers transactions and declined authorizations for anything suspicious - high number of declines, unusual amounts or merchants.
- Ask the customer to talk you through their recent card activity and confirm that it was done by them. Recording evidence for the confirmation is a good practice.
Once you are convinced that the customer is a good actor, you may reactivate the card.
Any disputes filed by the customer for activity that happened prior to reactivation will automatically be decided against you.
Releasing an Authorization Hold
Authorization holds are a mechanism that is used by card processor to verify and guarantee the availability of funds in the cardholder's account before providing any goods or services. The seller will put a hold on the funds, and while that hold is in place, they can request that the funds are paid to them. Sometimes, for various reasons, the seller does not release the authorization hold appropriately. These cases should be rare and typically result from a technical issue or user error. In these cases, if the hold causes a cash flow issue for the end customer, they might contact you, and you might choose to release the hold.
Manual release is an exception workflow. It does not change the normal authorization flow: in the standard case, the hold is released when the merchant settles or reverses the authorization, or when the card network no longer reports the hold as active.
There is also not a blanket automatic release at exactly 30 days for every authorization. Timing varies by network and merchant category, so some holds can legitimately remain longer.
You can release a hold from the Unit Dashboard (authorization details; Admin users only) or programmatically using POST /authorizations/{authorizationId}/release when your Org Bank Agreement allows org-initiated release. Otherwise, this remains a Unit-managed support action. See also Authorizations — Org-initiated release.
Best Practices
Unit does not recommend releasing authorization holds yourself. The recommendation is to ask the customer to contact the merchant to release the authorization, and if unsuccessful, create a support ticket. Unit can take steps on your behalf that you cannot - e.g. confirm with the network and merchant whether the hold is still active and if they intend to request the funds.
- Only Admin users have access to release authorizations.
- It is highly recommended to implement secure sign in
- It is required that you take the customer through customer identity verification.
- Confirm that the end customer has reached out to the merchant and was not able to get the authorization released through them.
If you are convinced that the end customer is not a bad actor, you may release the authorization hold.
Once you release a hold, the customer can spend the funds. If they do, and then the seller requests the funds, the request must be honored, and the end customer's balance might become negative, which might result in a financial loss if not covered by the end customer.
Reseting The Card PIN
Customers may forget their PIN, or miskey it, resulting in the PIN being locked. If that happens, they are likely to call your support team and ask for assistance in re-setting the PIN. This is a highly sensitive action so it's critically important that you verify the customer's identity before performing that action.
Best Practices
- Only Admin users have access to reset PINs.
- It is highly recommended to implement secure sign in
- It is required that you take the customer through customer identity verification.
If you are convinced that the end customer is not a bad actor, you may reset the PIN.