# Error Resolution/Process Handling

#### Error Resolution/Process Handling <a href="#error-resolution-process-handling" id="error-resolution-process-handling"></a>

Inyo maintains a ticketing system to handle all issues faced by SMP or users. The Customer Support Representative shall report any error or issue via email to <help@inyoglobal.com>. The tickets will be assigned to the designated personnel and will be responded to according to the timeline for each type of issue discussed below.

**Error/Process Types**

The various issues that SMP or a user can face and the methods to handle such situations are briefly explained as follows:

**Technical Issues**

Technical issues are malfunctions or bugs in the system that prevent users from successfully signing up, logging in or creating transactions in the system. The various technical issues are categorized as follows:

**Critical Issues**

Technical issues are identified as critical when they affect a wide range of users and needs immediate fixing for the service to function are categorized as critical issues. It can be one of the following:

* **Server Down:** Users may not be able to access the SMP Platform; (When server is down, ‘Error 500’ is displayed.)
* Multiple users are unable to login to the SMP Platform;

**Communication Protocol:**

For all critical issues, the Customer Support Representative shall send an email to Inyo Support (<help@inyoglobal.com>) with Subject line *Critical: ………. (Nature of Issue)*.

For example:

*Subject: Critical: Multiple users facing Server Error/unable to access the website*

The communication timeline for such issues are as follows:

* **Initial Contact:** < 2 hours
* **Status Update:** 2 hours
* **Management Escalation:** Immediately.

**Noncritical issues**

Non-Critical issues are issues/errors that are faced by specific users in the process of signup, login or creation of transaction. Some of the common noncritical issues are as follows:

**Technical Issues**

A user may face technical issues while signing up, transaction creation etc. Some examples of such technical issues are as follows:

* User unable to upload ID;
* User receives error message while moving to the next step during signup;
* User is locked and does not receive the reset email;
* Error adding funding source;
* MFA code not received;
* Unable to create transaction request;
* User receives message saying please contact customer support before creating any transaction;
* Error on page, etc.

The Customer Support Representatives shall follow the following procedure to resolve such issues:

**Role of Customer Support Representatives:**

Step 1: The customer support representative shall advice the user with First Level Solution as specified in **Annexure I**.

Step 2: If the issue is not resolved in Step 1, Customer Support Representative shall report the issue to Inyo support with the following information:

* screenshot of the error,
* version of the browser and
* operating system.

The subject of the email shall be as subject line: *TECH:………… (Nature of issue)*.

For example,

*Subject: TECH: User unable to Upload ID*

The issue shall be resolved by Inyo within 24 business hours of reporting of issue. However, in cases where Inyo needs to coordinate with partners or the user, it may take more than 24 business hours to resolve the issue.

Step 3: Customer Support Representative shall update the user after the issue is fixed (via emails or phone calls).

**Non-Technical Issues**

**Issues in Transaction Payout**

The transaction payout may be delayed or cancelled if:

* The prefund float maintained by SMP is insufficient.
* There are issues in sender/beneficiary/transaction compliance checks.
* The payout partner is facing a service disruption.
* The payout information provided by the user about the beneficiary is incorrect or incomplete. E.g.: incorrect beneficiary bank details.

(Note: A transaction can be REFUNDED if the user requests for it on any of the above delivery failure reasons. Any fee incurred against transaction refund shall be billed to SMP as per actual. However, a transaction can be RESENT for delivery for reasons mentioned above in 1 & 3 only.)

The steps to handle such issues are as follows:

**Roles of Customer Support Representatives**

Step 1: Forward the transaction details to Inyo and request for the reason for the delivery failure of the particular transaction to Support email with *subject line: PAYOUT FAILURE*

For example,

*Subject: PAYOUT FAILURE*

Inyo team will respond within 24 business Hrs.

Note: In cases where Inyo needs to coordinate with its service providers or the user, it may take more than 24 business hours to solve the issue.

Step 2: Customer Support Representatives shall inform the user about the delivery failure of their transaction and ask if they would like to resend/refund the transaction, depending on the reason for delivery failure.

Step 3: Customer Support Representatives shall then request Inyo to refund or resend the transaction as requested by the user.

Step 4: Customer Support Representatives shall inform the user that their transaction has been refunded or resent for payout accordingly.

**KYC Verification & Other Compliance Issues**

Some examples of compliance issues are as follows:

* User unable to get verified
* User unable to complete KYC process
* User KYC status is “Review Pending” for more than one (1) business day

The steps to handle such issues are as follows:

**Roles of Customer Support Representatives**

Step 1: Check on the details of the KYC failed reasons from the sender profile.

Step 2: Based on the KYC notes, take appropriate actions by moving user to different KYC status. Refer Annexure II for the KYC notes and Next Steps.

Step 3: After the user has submitted required documents or details, inform Inyo via emails to update on the user. (Inyo will be monitoring user verification as well. Please contact Inyo if there is some delay or any issue in this user verification process.)

Step 4: Customer Support Representatives shall update the user accordingly.

**Update KYC details of Verified users (Editing profile of sender and beneficiary):**

A previously verified user may need to update their KYC details in various scenarios. The details of the senders that can be changed are as follows:

* Name
* Date of birth
* Address (Includes full address with State)
* Phone number
* Email
* SSN
* Occupation details (Level 3 users)
* Occupation
* Company name
* Company Address
* Company phone number
* Designation

The details of beneficiary that can be edited are as follows:

* Full Name
* Address
* Phone Number

Methods of handling profile edit requests is given below:

**Roles of Customer Support Representatives:**

Step 1: SMP shall obtain the information from the user that needs to be updated.

Step 2: Forward the profile edit request to Inyo with the KYC details that need to be updated along with documents supporting such update request.

Step 3: Inyo will verify the update request and confirm such updates in the user dashboard. The update process shall be completed latest by 48 hours from the date of request.

Step 4: After the update is confirmed by Inyo, SMP shall make necessary changes in their database.

Step 5: Inform the user after the profile update has been approved/rejected.

**Requirements for profile edit:**

SMP shall be required to provided respective documents as follows for any profile update request:

| S.no | Profile Edit (Sender)                                       | Supporting Documents                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                           |
| ---- | ----------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| 1    | <p></p><ul><li>Name</li><li>Date of Birth</li></ul>         | Copy of Valid ID showing the updated information                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               |
| 2    | Address                                                     | <p></p><p>Valid Proof of address is required for editing the address details of the user. The proof of address will have 3 months validity where user name, address, and valid date should be visible. We can accept the change in state within the licensed states of a given license provider only for the time being. The documents that are accepted as proof of address are as follows:</p><ul><li>Utility Bills</li><li>Bank statements</li><li>Insurance paper</li><li>Purchase bill</li><li>Other (Any document which clearly shows the address of the user)</li></ul> |
| 3    | <p></p><ul><li>Phone number</li><li>Email Address</li></ul> | Reason for change                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                              |
| 4    | SSN                                                         | Copy of SSN                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    |
| 5    | Occupation Details                                          | Occupation details edit required a valid set of occupation detail of the user. There is some information that can be found on the internet regarding the address or phone number of the company. However the company name, designation should be clearly mentioned while editing the occupation details.                                                                                                                                                                                                                                                                       |
| 6    | Profile Edit (Beneficiary)                                  | Supporting Documents                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                           |
| 7    | Full name                                                   | Not Applicable                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                 |
| 8    | Address                                                     | Not Applicable                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                 |
| 9    | Phone number                                                | Not Applicable                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                 |

Note: The KYC details cannot be changed when the user has an ongoing live transaction.

**Sender name and bank account name mismatch:**

The system flags transactions in case there is a mismatch in the sender name and the bank account name for the bank added by the user. The flag can be seen in the user profile as well as transaction reports. SMP must build a feature to HOLD payout of such transactions. The process to handle such flags is as follows:

**Roles of Customer Support Representatives**

Step 1: The customer support staff should immediately check the bank added by a user if the bank flag appears in a transaction.

Step 2: If the bank flag is occurring due to minor issues like mismatch or absence of middle name, use of initials, etc. which prima facie does not raise a contention to the Customer Support Representative that the user is using a third-party account, SMP may allow the transaction to process further.

Step 3: In case of a material mismatch, the delivery of the transaction should be kept on hold.

Step 4: The Customer Support Representative should communicate with the user to clarify the issue of the name mismatch. If the case is of joint account, the user should be requested to provide joint account statement. In other cases, where the user is not able to justify the mismatch, payout of the transaction should be held and the Customer Support Representative should initiate refund procedure.

**Methods for Handling on “Hold” Transactions**

Transactions may be placed on “Hold” for multiple reasons which will be provided to the SMP’s via SMP dashboard *(See section Transaction Status)*. The “Hold” transaction handling procedure is described below on the basis of “Hold” reasons:

**KYC Not Verified**

The Customer Support Representative must communicate with users to complete their KYC process. However, if the user is in “Review Pending” status, Customer Support Representative should communicate with Inyo as per procedures outline in the KYC Verification & Other Compliance Issues section above.

**GEO IP Failure**

Step 1: The Customer Support Representative must communicate with the users to provide Proof of Address that they are residing within the States supported by the Program.

Step 2: The Customer Support Representative must collect Proof of Address from the user and upload it via Dashboard under document type “Other”.

Step 3: The Customer Support Representative must notify Inyo to review the document.

Step 4: Inyo shall review Proof of Address. If the document is sufficient, the transaction will be moved to “Initiated” status, otherwise the transaction shall be cancelled.

**Risk Score**

A transaction is placed on “HOLD” if a transaction is assigned a Moderate Risk score. SMP must review such transactions and request Inyo to either process or cancel the transaction, based on their assessment of the genuineness of the user and the transaction.

**Receiver wallet unverified:**

A transaction is also placed on “Hold” if the wallet of the receiver is unable to be verified. SMP should review such transaction and should communicate with the user regarding the wallet details that users have added. Following step should be taken:

Step 1: The Customer Support Representative must communicate with the users to verify wallet number, wallet holder name is correct or not, also if the wallet is active, suspended,

Step 2: The Customer Support Representative must collect such information and after all these details has been confirm, they should contact Inyo providing these information

Step 3: The Customer Support Representative must notify Inyo to review the details

Step 4: Inyo shall review the details and, if the required document/details are sufficient, the receiver’s wallet should be verified and then transaction will be released.

**Issues in Transaction Cancelations**

In case a user requests cancelation of any transaction, it may be cancelled if the transaction has not yet been processed or paid out. The steps to handle such transaction cancelation are as follows:

**Roles of Customer Support Representatives**

Step 1: Forward the transaction details to Inyo and request for cancelation to Support email with *subject line: TRANSACTION CANCELATION REQUEST*

For example,

*Subject: Transaction Cancelation Request for Transaction ID ……*

Inyo team will respond within 24 business Hrs.

Step 2: If the transaction has already been processed, a refund for the transaction can be initiated after three (3) business days from the date of settlement of funds.

Step 3: Customer Support Representatives shall update the user accordingly.

**Methods for Handling Returns**

SMP are solely responsible and liable for all transaction returns. The following steps are merely suggestions based on our experience. The discretion to follow the steps entirely lies with SMP. Returns needs to be handled differently based on the reasons they were returned. The various return handling procedure is described below on the basis of the return reasons:

**For return code R01**

When a transaction gets returned with reason insufficient funds, the Customer Support Representative shall contact the user to obtain authorization for reprocessing of the returned transaction or request the user to create a new transaction. Please go through the following workflow for handling this type of return.

**Roles of Customer Support Representatives:**

Step 1: Inform the user about the returned transaction.

Step 2: Take balance confirmation from the user (Get their bank statement to verify the balance) or request the user to maintain sufficient balance in the account so that the transaction can be reprocessed.

Step 3: Request Inyo to reprocess the returned transaction or ask the user to create a new transaction of the same value and the same beneficiary details.

Step 4: If the user creates a new transaction, request Inyo to adjust the exchange rate as per the returned transaction.

Step 5: Change the delivery status of the reprocessed transaction from “Pending” to “Delivered” manually to avoid payout of the transaction such that the new transaction is not delivered but only processed to recover the value of transaction that was initially returned.

**For return reasons related to bank account issues of the sender.**

This happens for the returns with return codes RO2, R03, R04 and R020. A transaction may be returned due to various issues in the bank account like bank account closed, invalid bank account details or bank account not found. In these cases, the transaction cannot be reprocessed and the user will be required to create a new transaction by correcting the details of the funding source. Following is the workflow to handle these types of returns.

**Roles of Customer Support Representatives:**

Step 1: Inform the user about the returned transaction

Step 2: Ask the user to add the funding source again; whether the same funding source by providing the correct credentials or a new funding source.

Step 3: Ask the user to create a new transaction with the same amount and beneficiary details.

Step 4: Inform Inyo once the user creates new transaction so as to adjust the exchange rates in the new transaction.

Step 5: Change the delivery status of the new transaction from “Pending” to “Delivered” manually to avoid payout of the transaction such that the new transaction is not delivered but only processed to recover the value of transaction that was initially returned.

**For returns related to chargebacks**

This scenario is generated when a user gets returned with return codes R07, R08 and R010. In these cases, the transaction cannot be reprocessed. The user needs to create new transaction to settle the returned transaction. However, before creating new transaction, SMP must ensure that the user has removed any stop payment orders or Authorization revocation instruction with their bank. Please refer to the following workflow to handle such types of returns:

**Roles of Customer Support Representatives:**

Step 1: Inform the user about the returned transaction

Step 2: If the user is ready to place new transaction, ask the user to clear the instructions (stop payment, customer advised not authorized etc.) with the bank.

Step 3: Notify Inyo after the user has cleared the instructions with the bank.

Step 4: Request the user to create new transaction by using the same bank account or by adding a new funding source (not the same bank account).

Step 5: Inform Inyo once the user creates new transaction so as to adjust the exchange rates in the new transaction.

Step 6: Change the delivery status of the new transaction from “Pending” to “Delivered” manually to avoid payout of the transaction such that the new transaction is not delivered but only processed to recover the value of transaction that was initially returned.

**Handling Refunds**

The Customer Support Representative shall handle refunds in the following manner:

**Refund request by User**

**Roles of Customer Support Representatives:**

Step 1: Request for the bank statement which shows the actual debit for the transaction amount.

Step 2: If the user is unable to provide their bank statement, SMP should wait till the return window is over (three days from the transaction processed date).

Step 3: Raise a ticket with Inyo for initiation of refund along with the relevant documents.

**Transaction Payout failures**

There can be cases when the transaction fails for instance, incorrect beneficiary details or a noncompliant transaction. In such case, SMP must initiate a refund after informing the user accordingly.

**Roles of Customer Support Representatives:**

Step 1: Inform the user about the failed transaction.

Step 2: Raise a ticket with Inyo to initiate the refund for the failed transaction.

Step 3: Inform the user regarding the refund after Inyo has confirmed the same.
