Intro to Risk
Last updated
Last updated
Risk, with regard to financial products, typically falls into two primary categories: Financial Risk and Regulatory Risk. While Financial Risk leads to direct losses to your operating capital, Regulatory Risk can lead to regulatory fines or other penalties. Ultimately both categories of risk have the potential to impact your operating capital, can impact your reputation, and in extreme cases may lead to the suspension of your program altogether.
Since both categories can cause disruptive events for your business, we recommend building Financial and Regulatory risk reduction strategies. In this resource, we will break down both types of risk and provide guidance to help you address them.
Financial Risk exists when a user spends funds in their account without intending to repay them or uses the "float" (the time it takes for transactions to process and settle) to overspend. In the case of Credit Hub, this can occur by taking credit from you, but then defaulting on the repayment obligation. While in the case of Deposit, it can occur by funding their account via one of the Payment Accounts and spending the funds knowing that that original transaction will return, thus overdrawing their balance and leaving the platform with limited options to recoup funds. Other than Provisional Credit and Credit Extensions, financial risk is primarily created by providing customers access to Payment Accounts. Since payments can return up to 60 days after a credit has been applied to a customer's account, payment processing exposes you to financial loss risk.
Based on the above statement, a valid conclusion is that most of your financial risk can be adjusted by adjusting access to Payment Accounts. With that in mind, here are some examples of how you might choose to design your Financial Risk Policy, based on your overall risk appetite:
We currently provide a solution for ID Score. Go to ID Score Product Guide to learn more.
Following are more details on Financial Risk by types:
ACH is a one-way messaging system for payment processing. Meaning, that a transaction in ACH is assumed to have succeeded unless the receiving bank sends a failure notice.
Based on the reason for failure, the receiving bank can have up to 60 days to return a transaction, assuming they have return rights. In practice this means if you released an ACH credit in 3 business days to your user, you might still receive a return up to 57 days later. Here are the most common return reasons:
❌ = Will not lock the user or node. ✅ = Will lock the user or node.
These returns are broken into three categories:
These returns occur when the account holder of the ACH account informs their bank (receiving bank) that the transaction was not authorized by them. NACHA guidelines allow account holders to take up to 60 days to dispute these kinds of transactions. Return codes R07, R10, and R29 signify unauthorized returns.
Administrative returns indicate that a transaction was returned due to administrative or account data errors. They occur within 3 business days of settlement. Return codes R02, R03, and R04 signify administrative returns.
Auto rejection logic is in place for ACH returns that occur 60 days or greater after transaction settlement. If an ACH return request is received after 60 days of the payment settlement date, the request will not be honored.
The rest of the returns are just other types of returns allowed by the ACH network. Like Administrative, these returns also occur within 3 business days of settlement.
Dishonoring a return is only allowed in circumstances where the return notice is late. This means, if Administrative and Other returns are coming to us after 3 business days or Unauthorized are coming after 60 days, then they can be dishonored. Otherwise, all other ACH Returns must be honored in compliance with the NACHA consumer protection guidelines.
Unlike ACH, Interchange (more popularly know as acquiring) is capable of giving you failure notices in realtime in almost all circumstances. However, there are some scenarios, known as chargebacks that can take up to 120 days.
Based on the reason for failure, the receiving bank can have up to 120 days to fail a transaction. This means, if you released an Interchange credit instantly to your user, you might still receive a failure notice (also known as a Chargeback) up to 120 days later. Here are the most common failure reasons:
Card processing presents both return and chargeback risk, which are different types of returns. An interchange return refers to a transaction being rejected by the network when it is unable to be processed for a variety of reasons. Meanwhile, chargebacks take place when a transaction occurs and settles, but a user disputes the transaction with the card issuer.
Card returns don’t create direct financial risk to platforms because transactions are immediately rejected and funds are sent back to the user in real time. Nevertheless, it's good practice for you to build logic to keep track of card returns, we have found that successive returns can be a red flag for future chargebacks and/or fraudulent activity. TRAN|PATCH webhooks will notify when returns occur.
All IR failure codes are instant, except IR999. IR999 is considered an unauthorized chargeback. This means that the customer claims that they did not authorize this transaction and the user has up to 120 days to dispute interchange transactions with this failure code.
High chargeback rates can potentially lead to substantial fines by card networks, inclusion on the Terminated Merchant File for up to 5 years (a list of merchants deemed high-risk by card networks), and/or suspension from the card networks.
Chargebacks also present financial loss risk as any negative balance, resulting from chargebacks will be reconciled from the platform’s reserve account.
Regulation E sets forth time limitations for disputed transaction investigations. Financial institutions may take up to 120 days to investigate the reported dispute/error. During the beginning of this period, you have the option to submit evidence against the dispute via the Dispute Chargeback API call. Common examples of evidence are email communication & interactions, shipping verification, phone call transcripts, live chat transcripts, social media interactions, and similar. We will submit all evidence to the network for investigation.
Due to the zero-liability policies of card networks (e.g. Visa, Mastercard), if the transaction is proven to be unauthorized you will have to pay the amount of the chargeback (i.e. the funds the platform received plus the interchange fee of the original transaction), regardless of whether they believe the transaction is fraudulent or not. The end user will receive credit for the transaction.
An exception to the zero-liability policies would occur if there is evidence that the user was grossly negligent or if there was a substantial delay by the user in reporting the unauthorized transaction to its card issuance institution. Evaluating when this exception applies will be at the discretion of the card networks, platforms can submit evidence prior to evaluation of their case.
Unlike ACH and Interchange, FedWires do not pose a financial risk to you as they are only outgoing, so there is no risk of returns and financial losses. However, it's important to note that FedWires are irreversible. So it is important to ensure that they were indeed originated by the sender and all the details submitted are accurate before originating them with us.
This can be done by features like enabling MFA right before originating a FedWire and showing the customer a summary page and urging them to check all the details before origination.
Though FedWires do not fail for lack of funds, they can still fail for the following reasons:
Recalling a wire is a process that requires us to contact the receiving bank and requesting them to reverse the wire back to us. This process is manual and the likelihood of success is low. It is also important to understand that financial institutions have no requirement to respond to our recalls. For that reason, we recommend Originating Wires Safely. But in rare situations that wires still need to be recalled, please create a ticket requesting a wire recall by emailing help@synapsefi.com.
SWIFT behaves similarly to FedWires. They do not pose a financial risk to you as they are only outgoing, so there is no risk of returns and financial losses. However, it's important to note that SWIFT Wires are irreversible. So it is important to ensure that they were indeed originated by the sender and all the details submitted are accurate before originating them with us.
This can be done by features like enabling MFA right before originating a SWIFT Wire and showing the customer a summary page and urging them to check all the details before origination.
Though SWIFT Wires do not fail for lack of funds, they can still fail for the following reasons:
Recalling a wire is a process that requires us to contact the receiving bank and requesting them to reverse the wire back to us. This process is manual and the likelihood of success is low. It is also important to understand that financial institutions have no requirement to respond to our recalls. For that reason, we recommend Originating Wires Safely. But in rare situations that wires still need to be recalled, please create a ticket requesting a wire recall by emailing help@synapsefi.com.
Under the hood, RPPS is just a private ACH rail. Since all RPPS transactions are push transactions, they do not pose a financial risk. Even though RPPS do not fail for lack of funds, they can still fail for the following reasons:
Like RPPS, checks are another way for your users to pay bills. Since they are credit only, they do not pose a financial risk. Even though checks do not fail for lack of funds, they can still fail for the following reasons:
If a check payment has not SETTLED yet (refer to Possible Transaction Statuses), the user can still choose to stop the check payment using Cancel Transaction API call.
Like ACH, RDC is a one-way messaging system for payment processing. Meaning, that a transaction in RDC is assumed to have succeeded unless the receiving bank sends a failure notice.
Based on the reason for failure, the receiving bank can have up to 60 days to fail a transaction. This means, if you released an RDC credit in 3 business days to your user, you might still receive a failure note (also known as a Return) up to 57 days later. Here are the most common return reasons:
These returns are broken into three categories:
These returns occur when the account holder of the bank account that the check belongs to informs their bank (receiving bank) that the transaction was not authorized by them or points out some other fraudulent issues with the check. RDC guidelines allow account holders to take up to 60 days to report checks as unauthorized. Return codes CHR03, CHR14, CHR17, CHR24, CHR25, and CHR26 signify unauthorized returns.
Administrative returns indicate that a transaction was returned due to administrative or account data errors. They occur within 3 business days of settlement. Return codes CHR02, CHR03, and CHR04 signify administrative returns.
The rest of the returns are other types of returns allowed by the RDC network. Like Administrative, these returns also occur within 3 business days of settlement.
If an RDC is returned due to forgery, there is no time limit against its return.
Even though we are the lender of record on all loans issued through Credit Hub, you are still the guarantor of all credits extended through your platform (see Credit Terms to learn more).
For that reason, it's important for you to have a credit underwriting strategy. A good credit underwriting strategy should try to assess two things:
Propensity to Pay
Willingness to Pay
A good way to understand a user's propensity to pay is by getting a holistic understanding of the user's debt-to-income ratio. This means understanding all the income sources and all the debt obligations the user has on a regular basis. There are quite a few tools in the market for this like traditional FICO or Plaid's Assets and Liability features are a good way to measure a user's debt-to-income ratio.
A good way to understand a user's willingness to pay is to measure the user's engagement with your platform. If a user finds value in your products and services, they will be more inclined to pay back the obligations through your platform over others.
Based on the above definitions, here are some examples of how you might choose to design your Credit Risk Policy, based on your overall risk appetite:
If you are going to issue Debit or Credit Cards to your users, then you also need to consider the financial risk of issuing provisional credits. Since you will lose most disputes, these credits are a source of financial losses for all FinTech platforms providing card products. Most card transactions that are disputed, are entitled to a provisional credit.
To learn more about Card Disputes and Provisional Credits, See Card Disputes Guide.
Regulatory Risk can lead to regulatory fines. Which impacts your operating capital and in extreme cases can cause suspension of your program altogether.
As a part of building a financial product, you are also expected to comply with UDAAP, Reg E, Fair Lending, and any other applicable financial regulations. As we build your program, we also provide specific guidance on how to comply with those regulations.
Synapse is responsible for transaction monitoring as part of our relationship with our partner banks. We work with our financial institutions behind the scenes to investigate and report activity as we monitor transactions across your platform. Due to the confidential nature of these reports, we are unable to share if or when we recommend a transaction or a user to be reported to FinCEN and/or other government agencies.
It is important to understand that Synapse's transaction monitoring and reporting structure does not absolve any obligations that you may have as a company independent of Synapse. For example, if your business is registered with FinCEN, and therefore has its own screening and reporting obligations, Synapse does not provide these controls as a service to you.