QFD can integrate either via REST or SOAP using real time API calls to the system of record in order to search for and retain useful account information.
Account Search:
Please note: QFD only supports looking up a list of accounts by the unique customer id.
The following data points will need to be returned from the account search API call, so that QFD can display the list of accounts on the UI, in order for the end user to confidently select the correct account to create the claim against.
Field | Required? | Comments |
|---|---|---|
Account Number | Yes | Unique account number that would identifies a customer’s account |
Description | Yes | ex: Checking, Business Checking, Student Checking, etc. |
Account Type | Yes | Indicates if the account is for deposits, credit cards, etc. Currently supported types are “Deposit” and “CreditCard”. Client data that derives the account type should not change. Ideally it is an alphanumeric or numeric code (not a text based description). |
Account Nickname | No | Can be used on the UI in place of the Description for easier account identification, sometimes enabled for those with online banking |
Account Lookup:
Note: This can leverage the same API call as Account Search, if the API supports being able to query based on EITHER a unique customer id OR a unique account number.
In order for QFD to retain needed account information, we will need as many of the following data points as possible to be made available from the API response:
Field | Required? | Comments |
|---|---|---|
Account Number | Yes | Unique account number that would identifies a customer’s account |
Account Type | Yes | Indicates if the account is for deposits, credit cards, etc. Currently supported types are “Deposit” and “CreditCard”. Client data that derives the account type should not change. Ideally it is an alphanumeric or numeric code (not a text based description). |
Account Status | Yes | This can either be a Alphanumeric or numeric code that represents status, or a string like “Active”, “Closed”, “Blocked”, etc.. Ideally this will be based on an unchanging code and not a text based description. |
Card Number | Yes | If the transaction API cannot return full card number, see next field. |
Card ID | Yes/No | If the API is only able to return Card ID, we will need a separate API call that supports being able to look up the full card number using the Card ID |
Card Status | Yes | If card data cannot be provided in the transactions API, we will need a separate API call able to get this information as card status will be needed for block and reissue |
Description | Yes | ex: Checking, Business Checking, Student Checking, etc. |
Account Nickname | No | Can be used on the UI in place of the Description for easier account identification, sometimes enabled for those with online banking |
Account Closed Date | No | Indicated the date the account was closed |
Account Open Date | No | Indicates the date the account was opened |
Balance | No | Indicates the current balance of the account |
Card Holder Name | No | The full customer’s name as written on the card |
Card Expiration Date | No | Indicated the date the card was/will be expired |
Card Issue Date | No | Indicates the date the card was issued |
Is Account Enrolled in Auto Pay | No | Indicated whether or not the account is enrolled in auto pay, if needed |
Is Overdraft Protection Enabled | No | Indicated whether or not the account has overdraft protection enabled, if needed |
Statement Cycle Date | No | Indicated the statement cycle date of the account |