API Documentation

Customer Application Demo Requirements

Suggest Edits

Application demo requirements for those seeking production access are outlined below.

👍

READY TO SCHEDULE YOUR DEMO?

  • Be sure to double check the Customer Application Demo: Check List to make sure you have not missed any required steps.

  • Click HERE to see the two options for submitting your sandbox application for a demo review.

/Register

Your application must include a notice about your customer identification program (CIP). You can accomplish that by incorporating the following text into your application during the registration process of your user onboarding UI. The language you use does not need to match the below verbatim, but it should closely match nonetheless.

  • A DOC_KYC flow must include the following language on why user meta data is being collected.
  • Introduction Screen:
    “For security purpose we need a few more details to prove that you're a real person”
  • Name/Address/DOB screen:
    “To help the government fight terrorism funding and money laundering, all financial institutions are required by federal law to obtain, verify, and record information about you, including your name, address, and date of birth. We may also ask to see your driver's license or other identifying documents.”
  • SSN Screen:
    “US Federal regulations require us to obtain your Social Security Number to confirm your identity. This will not impact your credit.”
  • If your app makes use of kyc_level: KYC-LITE in addition to DOC_KYC flows then you must show the transition from one KYC level to the next highest KYC level.
  • Private keys:
    • User private keys must never be generated client side.
    • User private keys must not be communicated over any network unencrypted
    • User private keys must be stored and retrieved with the use of a Key Management Store

❗️

Info Management and Security Requirements

All applications must adhere to Sila's Information Management and Security Requirements for:

  • Encryption Standards
  • Database Hosting
  • Key Management Store (KMS)
  • Logging Data
  • Database Access
  • Data Disposal
  • Security Integration

/request_kyc for individuals

  • Applications which make use of DOC_KYC must show the unhappy path where users fail their KYC evaluation and are subsequently asked to update information and/or send in verifying documents.
  • User’s are allowed to fail KYC and update their meta data once. If they fail again they must upload documents to verify their identity.
  • Users who fail KYC should be presented with the list of documents and document requirements which can be used to verify their identity (see: triaging-kyc-failures). In some cases this could be multiple lists--eg. They failed with multiple tags. In other cases one document can satisfy multiple failure scenarios (eg. A driver's license verifies Name and DOB). How you handle this is up to you, but you must never display the reason tags to your end user.
  • Document uploads are handled through the /documents endpoint and kyc_level: DOC_KYC.

/request_kyc for businesses

  • Everything for individuals applies to businesses except you’ll use kyc_levels KYB-STANDARD and KYB-LITE. (see: kyc-kyb-levels)
  • All KYB implementations need to be compliant with US laws. End users must be asked to report if they are any of these three roles: admin, a controlling office, and/or a beneficial owner. It’s recommended that you go through the full KYB demo at http://demo.silamoney.com/ to see how a legal KYB flow is implemented.

🚧

KYC Failures and updating user meta data

In an effort to prevent fraud your users should only be allowed to fail KYC and update their meta data once. If they fail again after updating their registration data they must upload documents to verify their identity.

/link_account

  • Your Plaid implementation must send us a “selected_account_id”
  • Your Plaid implementation should follow the Processor Token method and does require you to have your own contract with Plaid.

    (Sila will support Legacy public token and Link integration for the near term, however, this functionality is marked to be deprecated on 01/01/2021. Please seek a direct relationship with Plaid to use our Processor Token functionality.)

  • Direct Account linking is prohibited for all end-user unless approved by Sila’s compliance team. You may use direct account linking to link your company wallet to your company bank account or for receive-only entities only.
  • If you have your own Plaid contract you must use the Plaid Processor Token method for your Plaid implementation.

📘

Selected account id in /link_account

The /link_account endpoint has a parameter "selected_account_id" which tells Sila which account the user selected in Plaid's Link Account modal. Without this parameter we will link the first checking account in the accounts array which we get back from Plaid.

To prevent errant bank account debits you are required to pass us the "selected_account_id" in your demo; this item comes from Plaid's onSuccess function and is synonymous with Plaid's "accountID". In other words, Sila's "selected_account_id" = Plaid's "accountID"

/issue_sila

  • Sometimes ACH transactions can be returned to the end user by their bank. Your customer support team must have a way to triage ACH returns.
  • Permanently delete the linked account if you receive ACH return codes in R02, R03, R04, R20, R13, R14, R15. Then contact the end user, and consider removing them from your platform
  • Transaction Authorization Screen: your application must have a screen or modal where the end user confirms their choice to begin a transaction request.
    • Include the transaction amount and bank account information (last four digits of the account number or bank account name) as well as any recurrence information.
  • Your application must inform users when to expect their funds. You can accomplish this by using our ACH Processing Calendar (see: ach-processing-schedule)
  • Your application must check the end user’s bank balance before authorizing a transaction when possible (see: /get_account_balance)
    • Your application is required to use the bank account balance to judge whether or not it is safe to perform a debit of the account. Obviously if they don't have enough money then you should prompt your user to choose a different amount.
    • Note that not all accounts can have their balances queried. You will need to handle these errors however you see fit. Eg. if you can’t query the balance then the user should be subject to a lower transaction limit, or you should delay giving them access to their funds for 4 business days to ensure no returns occur.

👍

Minimizing needless ACH returns

Generally speaking a bank account should have 150% percent of the transaction amount available for you to comfortably authorize a debit. Bank accounts with less than $100 generate far higher rates of ACH returns regardless of the transaction amount.

Think long and hard about how you will minimize your ACH return rate by employing common sense practices and by using all the tools available to you, such as /get_account_balance.

End users who regularly generate ACH returns should be removed from your platform permanently.

/transfer

If your application includes the movement of Sila tokens from one wallet to another then your demo will need to show this.

/redeem_sila

  • Sometimes ACH transactions can be returned to the end user by their bank. Your customer support team must have a way to triage ACH returns.
  • Transaction Authorization Screen: your application must have a screen or modal where the end user confirms their choice to begin a transaction request.
    • Include the transaction amount and bank account information (last four digits of the account number or bank account name) as well as any recurrence information.
  • Your application must inform users when to expect their funds. You can accomplish this by using our ACH Processing Calendar (see: ach-processing-schedule)

Other:

Your demo needs to show how users can access your ToS and Privacy Policy

  • Your website must have a Terms of Service which includes our required language and links back to Sila’s ToS.
  • Your website must have a Privacy Policy which includes our required language and links back to Sila’s Privacy Policy
  • Our required language is provided to you via your Process.St checklist
  • End users must agree to your ToS and Privacy Policy during their onboarding

Updated about 3 years ago