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 [e-mail].

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 [e-mail].

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.