Intro to Risk

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

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:

Risk Appetite

Policy

Conservative

We will not provide payment origination products to any customers. All customers will be required to fund their accounts with us via direct deposit or cash deposits that do not pose return risk.

Moderate

Before the policy, here are some definitions: ID Score A probabilistic score (0-1) assigned to all users at the time of onboarding that predicts the likelihood that the identity supplied belongs to the person who is creating the account. 1 meaning we are 100% certain that the user is who they say they are. 0% means with 100% certainty we can say that the user is not who they say they are.

Risk Score A probabilistic score (0-1) assigned to all users who are utilizing their accounts which predicts the likelihood that their subsequent transactions will lead to a financial loss.

Policy Reducing Onboarding Risk

We will be utilizing ID Score to reduce stolen profiles in our system, the idea being that a user is less likely to fraud us with their real identity. If a user's ID Score is below 0.8, we will be collecting additional documentation and performing enhanced due diligence before onboarding them to the platform.

Reducing Ongoing Risk

On top of that, we will be utilizing Risk Score to put people in green (over 0.9), yellow (0.5-0.89), and red (below 0.5) paths. Where the green path will give users uninterrupted access to all payment products, yellow will reduce all payment limits by 50% and red will reduce limits by 90%.

Aggressive

We will provide all payment products to customers and assume that financial fraud is an acceptable risk to the business.

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

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.

Returns Codes

Code

Description

Locks Node

Locks User

R01

Insufficient Funds

R02

Account Closed

R03

No Account/Unable to Locate Account

R04

Invalid Account Number

R06

Returned Per ODFI's Request

R07

Authorization Revoked by Customer

R08

Payment Stopped

R09

Uncollected Funds

R10

Customer Advises Not Authorized

R11

Check Safekeeping Entry Return

R12

Branch Sold To Another DFI

R13

RDFI Not Qualified to Participate

R14

Account Holder Deceased

R16

Account Frozen

R17

File Record Edit Criteria

R20

Non-Transaction Account

R21

Invalid Company Identification

R22

Invalid Individual ID Number

R23

Credit Refused by Receiver

R24

Duplicate Entry

R29

Corporate Customer Advises Not Authorized

R31

Permissible Return Entry

R33

Return of XCK Entry

R34

Limited participation DFI

R68

Untimely Return

These returns are broken into three categories:

Unauthorized

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

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 of Late ACH 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.

Others

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

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.

Interchange

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:

Failure Codes

Code

Description

Locks Node

Locks User

IR01

More information is needed from the card issuer

IR02

Refer to card issuer's unique transaction rules

IR03

Not recognized as a valid merchant

IR04

Card not activated for transaction use

IR05

Suspicious activity; do not honor this card's transactions

IR06

Error during transaction process

IR07

Card has unique conditions; currently not activated for transaction use

IR08

Needs more identification to process the transaction

IR09

Transaction requested; currently in progress

IR10

Transaction amount partially approved

IR11

Approved but not processed

IR12

Transaction invalid

IR13

Transaction amount invalid

IR14

Card number does not exist

IR15

Card issuer does not exist

IR17

Customer canceled/reversed payment

IR18

The customer reversed the transaction: chargeback

IR19

Please retry the transaction

IR20

Response from the card processor was invalid

IR21

Transaction formatted incorrectly (Potential reversal detected)

IR22

Suspected malfunction, reversal

IR23

Transaction fee was unacceptable

IR24

File update not supported by receiver

IR25

Unable to locate record on file

IR26

Duplicate file update record, no action taken

IR27

File update field edit error

IR28

Field update record locked out

IR29

File update not successful, contact the acquirer

IR30

Transaction formatted incorrectly (Potential reversal detected)

IR31

Transaction must be initiated in person, bank not supported by "switch"

IR32

Completed partially, reversal

IR33

Expired card, pick-up

IR34

Suspected fraud, pick-up

IR35

Card acceptor must contact acquirer, pick-up

IR36

Restricted card, pick-up

IR37

Merchant must contact the card security

IR38

PIN tried too many times; request a new card or try again later

IR39

No credit account tied to credit card

IR40

Function requested can not be carried out

IR41

Lost card: request a new card

IR42

Account tied to card is not universal

IR43

Stolen card: request a new card

IR44

Investment account not on required

IR45 - IR50

Reserved for ISO use

IR51

Insufficient funds (NSF)

IR52

Checking account not associated with the card

IR53

Savings account not associated with the card

IR54

Card Expired: request a new card

IR55

Pin tried is incorrect

IR56

No record of the validity of the card

IR57

Transaction not permitted to cardholder

IR58

Transaction denied by acceptor (Potential chargeback detected)

IR59

Fraud suspected

IR60

Merchant must contact the card acquirer

IR61

Transaction exceeds card limits

IR62

Card restricted

IR63

Card information compromised (Potential chargeback detected)

IR64

Original amount incorrect, reversal

IR65

Current transactions exceeds withdrawal frequency limit

IR66

Merchant must contact the card acquirer

IR67

Hard capture

IR68

Response received too late, reversal

IR69 - IR74

Reserved for ISO use

IR75

Allowable number of PIN tries exceeded

IR76

Key synchronization error

IR77

Reserved for private use

IR78

Customer not eligible for POS

IR79

Invalid digital signature

IR80

Stale date transaction

IR81

Issuer requested standin

IR82

Count exceeds limit

IR83

Reserved for private use

IR84

Time limit for pre-authorization reached

IR85

Issuer has no reason to decline the transaction (Account Verification)

IR86

Cannot verify PIN

IR87

Check already posted

IR88

Card information not on file

IR89

Security code verification failed

IR90

Card cutoff is in progress

IR91

Card change in progress or not taking effect

IR92

Intermediate network/financial institution is unknown

IR93

Transaction is in violation of the law and will not be completed

IR94

Duplicate transaction

IR95

Error with transaction reconciliation

IR96

System error during transaction

IR97 - IR98

Reserved for national use

IR99

Card network error during transaction

IR100 - IR126

Reserved for ISO use

IR127

SEC is invalid

IR128

Address and verification check data is required for this transaction

IR129

Security code date is required for the transaction

IR130 - IR131

Transaction not permitted to cardholder

IR132

Country of the card issuer is blocked by this merchant

IR133

Incorrect MAC was sent

IR134

Standard Entry Class requirements were not met

IR135

System error during transaction

IR136

Account length error

IR137

Card information error

IR138

Security code format error

IR139

Internal authorization error

IR140

Card product code is blocked

IR141

Attempt to process a BRIC transaction on a prior PIN based transaction

IR142

CyberSource Time Out Connection to CyberSource timed out

IR143

CARD_ENT_METH supplied is not valid or required additional data not provided as defined

IR144

CARD_ID is not valid

IR145

Required PIN block not present

IR146

Card Bin is not valid for pin-less routing

IR147

Signature store did not complete

IR148

Debit PIN transactions must be swiped

IR149

DB proxy response was not processed within the time out period

IR150

Transaction declined by merchant to security code mismatch

IR151

Transaction not allowed as per a validation rule

IR152

Processing gateway full: poll again later

IR153

Authorization life cycle unacceptable

IR154

Authorization life cycled expired

IR155

Card authentication failed

IR156

Fraudulent transaction prior to embossed valid date

IR157

Credit not received

IR158

Allowable PAN entries warning -- approved

IR159

Transaction approved with card overdraft protection

IR160

Security code is invalid

IR161

Internal transaction processing error

IR162

Check not acceptable for cash

IR163

Check not acceptable

IR164

Check deposit limit exceeded

IR165

Cash back limit exceeded

IR166

Check amount does not match courtesy amount

IR167

PIN not selected for card

IR168

PIN already selected for card

IR169

Unmatched voucher information

IR170

Card number entered too many times

IR171

Expiration date not valid for card

IR172

Card status is set to inactive

IR173

Expiration date mismatch: request a new card

IR174

Item suspected for stop pay

IR175

Account associated with card was closed

IR176

Account associated with card is ineligible for the transaction

IR177

Duplicate transaction

IR178

No account associated with card on file

IR179

Unable to locate card

IR180

Transaction denied

IR181

Transaction settled via ACH

IR182

Cross-reference card not found

IR183

Category limit exceeded

IR184

Transaction limit exceeded

IR185

Daily limit exceeded

IR186

Monthly limit exceeded

IR187

Invalid secret code

IR188

Pin key sync error

IR189

Bad security code

IR190

Transaction ordered to be stopped

IR191

Transaction authorization revoked

IR192

Stop reoccurring payments

IR193

Card lost: do not honor

IR194

Account associated with the card is closed

IR195

Account associated with the card is inactive

IR196

Card has unique conditions: do not honor

IR197

Purchase only approval for purchase with cash back transaction

IR198

Card does not have sufficient funds for the transaction fees (NSF Card)

IR199

Card chip failed during transaction

IR200

PIN compromised

IR201

MasterCard MoneySend Error: Incorrect Expiration date

IR202

MasterCard MoneySend Error: Card declined due to an unknown reason

IR203

MasterCard MoneySend Error: Card declined due to unsupported card type

IR204

MasterCard MoneySend Error: Card declined due to an unknown reason

IR205

MasterCard MoneySend Error: Card declined due to an unknown Reason

IR206

MasterCard MoneySend Error: Card transaction request has an unknown status

IR999

Unauthorized Chargeback return

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.

Disputing a Chargeback

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.

FedWire

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.

Originating Wires Safely

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.

Failures

Though FedWires do not fail for lack of funds, they can still fail for the following reasons:

Code

Description

WR01

Return Per Customer Request - Returned per customer request.

WR02

Return Per Platform Request - Returned per platform request.

WR03

Account Closed/Frozen - The receiving account is closed/restricted/frozen, therefore the wire cannot be credited.

WR04

Compliance Concerns (Additional Documents Required) - We have identified red flags which require further investigation. The wire has been returned and we have requested additional documentation.

WR05

Country Not Allowed - The specified country is not allowed per the platform's controls and the wire has been returned.

WR06

Exceeds User's Limits - The transaction exceeds the user's daily, monthly, and/or annual limits.

WR07

Exceeds Platform's Limits - The transaction exceeds the platforms' daily, monthly, and/or annual limits.

WR08

Name Mismatch - The recipient's name in the wire instructions does not match the name on file with us.

WR09

Inactive Account - The receiving account is inactive, or unverified therefore the wire cannot be credited.

WR10

Invalid Account Number - The account number in the wire instructions does not match the account number on file with us.

WR11

Duplicate Transaction - Duplicate transaction, the duplicate has been returned.

WR12

Outside of Allowed Flow of Funds - The account number in the wire instructions is not a valid account number on file with us.

Recalling a Wire

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

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.

Originating Wires Safely

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.

Failures

Though SWIFT Wires do not fail for lack of funds, they can still fail for the following reasons:

Code

Description

R69

multiple errors: {e}

Failed to establish a new connection: Connection timed out

SSL: CERTIFICATE_VERIFY_FAILED

R83

transaction failure: {e}

Issue with Transfer API - Transfer failed to create

uncategorized error: {e}

Pending RouteFusion KYC Verification

Pending RouteFusion Beneficiary Verification

Unable to Retrieve Transfer

User Not Found

WR01

Return Per Customer Request - Returned per customer request.

WR02

Return Per Platform Request - Returned per platform request.

WR03

Account Closed/Frozen - The receiving account is closed/restricted/frozen, therefore the wire cannot be credited.

WR04

Compliance Concerns (Additional Documents Required) - Synapse has identified red flags which require further investigation. The wire has been returned and we have requested additional documentation.

missing information: {e}

The beneficiary country (FR) requires that the bank account be provided in IBAN format.

Issue with Beneficiary API - Missing Payload Information

WR05

Country Not Allowed - The specified country is not allowed per the platform's controls and the wire has been returned.

WR06

Exceeds User's Limits - The transaction exceeds the user's daily, monthly, and/or annual limits.

WR07

Exceeds Platform's Limits - The transaction exceeds the platforms' daily, monthly, and/or annual limits.

WR08

Name Mismatch - The recipient's name in the wire instructions does not match the name on file with Synapse for the account.

WR09

Inactive Account - The receiving account is inactive, or unverified therefore the wire cannot be credited.

WR10

Invalid Account Number - The account number in the wire instructions does not match the account number on file with Synapse.

WR11

Duplicate Transaction - Duplicate transaction, the duplicate has been returned.

WR12

Outside of Allowed Flow of Funds - The account number in the wire instructions is not a valid account number on file with Synapse.

WR13

Return per ODFI Request (Recall Received) - Returned per sending FI's request, a recall was received.

WR14

Detailed transaction reason not sufficient - The transaction details are not sufficient for Synapse to understand the purpose of the wire.

WR15

Beneficiary address invalid - The beneficiary’s address is either incomplete or invalid.

WR16

Beneficiary name invalid - The beneficiary’s name is either incomplete or invalid.

WR17

Below $1,000 USD minimum - Wire amount must equal at least $1,000 USD.

WR18

Verbal verification form required - The verbal verification form is missing from the transaction.

WR19

Verbal verification form invalid - The verbal verification form has at least one error that renders it invalid.

WR20

Correspondent bank details invalid - The name, address or ABA/SWIFT of the correspondent bank is invalid.

Recalling a Wire

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.

RPPS

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:

Code

Description

R02

Account Closed

R03

Account Number Invalid

R04

Wrong Account Number

R05

Pre-Notification Error

R06

Originator Requested Return

R07

Authorization Revoked

R08

Payment Stopped Settlement

R09

Uncollected Funds

R10

Advised Unauthorized

R12

Branch Sold

R14

Payee Deceased

R15

Beneficiary Deceased

R16

Account Frozen

R17

File Edit -Record Criteria

R18

Wrong Entry Date

R19

Account Error

R20

Non Transaction Account

R21

Wrong BillerId

R22

Account Number Mistake

R23

Payment refused by Biller

R24

Duplicate Entry

R25

Fair share Amount

R29

Advised Unauthorized

R31

Permissible Return Entry

R42

Routing Number Error / Check Digit Error

R43

DFI account Number

R61

Misrouted Return

R62

Trace Number Error

R63

Dollar Amount Mismatch

R64

Individual Identification

R65

Invalid Transaction Code

R66

Invalid Company Identification

R67

Duplicate Return

R68

Untimely Return

R69

Multiple Errors

R70

Permissible Return Entry Not Accepted

R71

Misrouted Dishonored Return

R72

Untimely Dishonored Timely

R73

Timely Original Return

R74

Corrected Return

R80

Cross Border Payment Coding Error

R81

Non-Cross Border Participant

R82

Foreigner Receiver ID

R83

Unable to Settle

R84

Not Processed

R85

Fair Share Rebate

Checks

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:

Code

Description

CHR03

Stop payment – a stop payment has been placed on the item

CHR15

Unable to process

Stopping Check Payment

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.

RDC

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:

Code

Description

CHR01

NSF – customer does not have sufficient funds to cover the item

CHR02

UCF – uncollected funds hold

CHR03

Stop payment – a stop payment has been placed on the item

CHR04

Closed account – the item’s account has been closed

CHR05

UTLA – unable to locate account

CHR06

Frozen/blocked account – account has restrictions placed by customer or bank

CHR07

Stale dated – the date on the item is more than 6 months old

CHR08

Post dated – the date on the item is in the future

CHR09

Endorsement missing

CHR10

Endorsement irregular

CHR11

Signature(s) missing

CHR12

Signature(s) irregular, suspected forgery

CHR13

Non-cash item (non negotiable)

CHR14

Altered/fictitious item/Suspected counterfeit/Counterfeit

CHR15

Unable to process

CHR16

Items exceeds stated max value

CHR17

Not Authorized (Includes Drafts/Remotely Created Checks) – Unauthorized item such as a draft/RCC

CHR18

Branch/account sold (Wrong Bank)

CHR19

Refer to Maker

CHR20

Item cannot be re-presented (exceeds allowable number of presentments

CHR21

Unusable image

CHR22

Cannot determine amount

CHR23

Refer to image – return reason is contained within the image of the item

CHR24

Duplicate Presentment (Supporting documentation shall be readily available)

CHR25

Forgery – an affidavit shall be available upon request

CHR26

Warranty breach (includes Rule 8 & 9 claims)

CHR27

RCC warranty breach

CHR28

Forged and counterfeit warranty breach (Rule 9)

CHR29

Retired/ineligible routing number

CHR30

Image Missing

CHR31

Ineligible Item

CHR32

Item cannot be re-presented (exceeds number of allowable times for presentment)

CHR33

unusable image

CHR34

Image fails security check

CHR35

Duplicate presentment

CHR36

Does not conform with ANS X9.100-181

CHR37

Does not conform to the Industry’s Universal Companion Document

CHR38

Warranty Breach (includes Rule 8 & Rule 9 claims)

CHR39

RCC Warranty Breach (Rule 8)

CHR40

Forged and Counterfeit Warranty Breach

CHR41

Retired/Ineligible Routing Number

These returns are broken into three categories:

Unauthorized

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

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.

Others

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.

RDC Forgery Fraud

If an RDC is returned due to forgery, there is no time limit against its return.

Credit Extension

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:

  1. Propensity to Pay

  2. Willingness to Pay

Propensity 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.

Willingness to Pay

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:

Risk Appetite

Policy

Conservative

We will not provide any unsecured credit products. Customers will be required to keep funds in a loan reserve which will equal to total credit issued to them.

Moderate

Policy Propensity to Pay

We will use Plaid's Assets and Liability features to measure a customer's propensity to pay. All users will need to have a debt-to-income ratio of lower than 0.5 to be approved for the loan. All loans provided will have an installment less than or equal to half of the user's monthly disposable income (income - existing debts).

Willingness to Pay

We will only solicit the user for a credit account after they have been using the platform for over 6 months.

Ladder Up

The users that do not fit the above parameters will only be offered secured loans and later laddered up into an unsecured loan.

Aggressive

We will provide $100 line of credits to customers to measure their willingness to pay and assume this as the cost of customer acquisition. Once history is built, the user will be able to request higher amount of loans.

Provisional Credits

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

Regulatory Risk can lead to regulatory fines. Which impacts your operating capital and in extreme cases can cause suspension of your program altogether.

Consumer Regulations

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.

Transaction Monitoring

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.

Last updated