DEBT COLLECTION SYSTEM ACCOUNT SUBMISSION FILE

Transcription

1 CAPITAL RESOLVE LTD. DEBT COLLECTION SYSTEM ACCOUNT SUBMISSION FILE (DCS-ASF1107-7a) For further technical support, please contact Clive Hudson (IT Dept.), /02/2012

2 Account Submission File Format This document is intended to describe debt submission files that can be loaded onto our Debt Collection System. This document is intended for the developers in your I.T. department and presents an idealized debt submission file. In practice, your operation may be forced to provide data in a different way, and we accept this. However, to keep costs down and to expedite setting up access to our services, please submit data in text-editable CSV format (specifically not XLS) starting with a header record containing field labels. Data Encryption We recommend you use WinZip using 256-bit AES encryption. The data that you send to us will contain confidential personal information which must be encrypted during transfer. Therefore, at some point we will need to exchange encryption keys or you must provide us with a password. Currently we can accept and recommend data encrypted using PGP or WinZip (preferred). If you are using another encryption scheme, then we will need to make special arrangements before you begin data transfers to us. It is recommended that a single encryption method is used routinely. Data Transfer Method Account Submission Files can be sent to us as attachments (depending on size), or we can download them directly from your own web or FTP site. It is recommended that a single transfer method is used routinely. Submission Tracking Once accounts are loaded onto our system, they are no longer associated with the submission file that they arrived in. Instead we record the date that the account was updated to our system and we call this the Submission Date. This is an important point because we use the submission date when we analyse and report our collection performance to you. It is possible that you submit a file at the end of one month, and then for us to process and load the data, assigning it a submission date set in the following month. If tracking accounts by submission date is not acceptable to you then please provide us with a batchtracking code field for each account. RECEIPT ACKNOWLEDGEMENT Depending on the volume of business, you should receive a letter or report detailing each account that you submit to us. Submission Frequency & Categories We would usually expect no more than one submission file per day. Sending multiple files per day is acceptable but not ideal since it increases the reliance on the applied file naming convention. Where there is a requirement for accounts to be grouped, and to avoid splitting different categories of work into separate files, you could provide a work-category field. This allows a single submission file to carry multiple categories of work. We will provide you with one or more Capital Resolve Client Prefixes during our new-business induction process. File Names While any file name acceptable to the Windows operating system is usable, it is recommended that those you supply to us adhere to the following convention: Page 2 of 8

3 The length of a file name should not exceed 50 characters. Use only alphanumeric characters and the underscore character. The letter case you apply is unimportant, however, Windows has a case insensitive file system, so it should never be relied on to create a unique file name. Do not use spaces, punctuation or symbols as part of the file name. These characters, although some are valid, are known to cause operational difficulties. The file name should be unique for all time. Submitting files that repeatedly use the same name creates a potential source for operational errors and can increase the complexity of our systems interface. Typically file names should include the date (in the format CCYYMMDD) and if more than one is submitted on the same day, the time (in HHMMSS format) or a unique serial number could be used. Use of the underscore character to separate major elements within the file name is recommended. File Extension Type Code The Windows operating system associates files to their application counterpart based on the file's extension type code. We would prefer to accept data supplied in plain ASCII text form, therefore the file extension type code would be ".TXT" or ".CSV". A benefit to using plain text is that a file can be easily inspected, and even corrected, using a simple text editor. Please try to avoid supplying information in ".XLS" or ".XLSX" (Excel spreadsheet format). Experience has repeatedly shown that using this format causes repeated operational problems when created by a person. Other technical complexities may also arise directly from the use of this format as a method of information interchange such as the unreliable transmission of large number fields, usually numeric-only reference numbers. It must be remembered that a spreadsheet will be converted to CSV format and processed by a machine which will not be able to compensate for unplanned deviations from the intended format and this could result in a delay in the processing of a submission file. File-Level Format Submission files may contain zero, one or more records. Empty files are acceptable but can cause operator confusion. Record-Level Format Each record must be terminated by a Carriage Return and Line Feed character (0x0D, 0x0A). These two characters are not considered part of the record. This document stops short of providing a full data-item schedule as it has been found that in the past, clients would hold back additional data items that are specific to your business and which would be of use to our collection agents. With this in mind, you are encouraged to provide as much useful information as you reasonably can. However, the minimum information that you should provide for every Consumer debt are: PERSON'S ACCOUNT IDENTIFIER PERSON'S TITLE FIRST NAME MIDDLE NAME OR INITIAL (if available) LAST NAME FOUR LINES OF ADDRESS (upto 30 characters on each line) Page 3 of 8

4 POSTCODE MOBILE TELEPHONE NUMBER (if available) HOME TELEPHONE NUMBER (if available) WORK TELEPHONE NUMBER (if available) DATE OF BIRTH (if available) ADDRESS (if available) DEBT/INVOICE REFERENCE NUMBER AMOUNT TO BE COLLECTED (no currency symbol - GBP is assumed) PRODUCT OR SERVICE DESCRIPTION (what the debt relates to) For Commercial debt we would require: COMPANY'S ACCOUNT IDENTIFIER COMPANY NAME CONTACT'S TITLE CONTACT'S FIRST NAME CONTACT'S MIDDLE NAME(S) (if available) CONTACT'S LAST NAME FOUR LINES OF ADDRESS (upto 30 characters on each line) POSTCODE MOBILE TELEPHONE NUMBER (if available) HOME TELEPHONE NUMBER (if available) WORK TELEPHONE NUMBER (if available) ADDRESS (if available) DEBT/INVOICE REFERENCE NUMBER AMOUNT TO BE COLLECTED (no currency symbol - GBP assumed) PRODUCT OR SERVICE DESCRIPTION (what the debt relates to) PLACED DEBT If you are a debt purchase agency or referring debt to us from a third-party client of yours, then in addition to the above we will need to know the name of the original client and their original reference number so that our agents can correctly identify themselves to the debtor by providing them with a meaningful customer reference or customer account number. Field-Level Format The expected character codes found within each field are (in hexadecimal) 0x20 through 0x7F, as shown in the ASCII character set in Appendix A. Control characters, 0x00 through 0x1F, must not appear within any data field. In CSV files, if a field contains a comma, then that field must be double-quote protected. NAME FIELDS Name fields are a critical data item as they identify an individual person either liable for the debt or, where the debtor is a company, a vital point of contact within an organization. The name should be supplied as a set of three separate fields: Title, First name, Last name. If you have a middle name or middle initial, then that would be useful to have as well. Titles are important. In some cases where the first name is foreign, not having the title makes it difficult for agents to know if the debtor they need to speak to is male or female. Page 4 of 8

5 STRING FIELDS Unless otherwise specified in the field's description, string fields may contain the character codes 0x20 through 0x7F. Please see Appendix A. Alphabetic data should be supplied in uppercase. In records using fixed-length fields, text must be leftjustified and space padded to the right. DATE FIELDS Dates should be supplied in the format: CCYYMMDD. The 2-digit components in this format are: CC Century YY Year in century MM Month number DD Day number Each component must be zero filled to two digits. For example, May 3rd 1971 would be presented as " " Date values should either be fully specified, or blank. Data faults, including incomplete or invalid dates, such as "2010", "201012" or " ", will be treated as if they were blank. It is acceptable to supply " " to indicate an unknown date. MONEY FIELDS Money amounts must be presented as a number accurate to two decimal places regardless of the currency. If the supplied value is below "1.00", then the decimal point must be prefixed by a zero, for example 23 pence is "0.23". Money fields must not be blank. Do not embed currency symbols or commas in the amount field. Money fields must only use the following characters: In fixed-length records, money fields must be right-justified and space or zero padded to the left of the data to make up the required length. SIGNED AMOUNTS All money values are assumed to be positive. A positive sign must not be used. If the amount is negative, a hyphen must immediately precede the left most digit, e.g. "-52.99". AMOUNT TO BE COLLECTED In the context of the amount to be collected, a positive amount is an amount that you require us to collect from the debtor. A negative amount would indicate that the account is in credit - and therefore no collection will be attempted. Zero and negative balances are acceptable; however, they imply that we will be operating an account administration service for which we may charge a pre-arranged fee. CSV File Format Care should be taken when submitting non-numeric data items in Comma Separated Value, specifically name and address data items. Where an address or person's name contains a comma, the whole field must be double-quote protected to prevent unwanted field shifting. Double-quote delimiting a field is not necessary if the data item does not contain a comma, double quotes nor embedded CR/LF markers. Currency amount fields should never contain comma separators or currency symbols. CSV files must always contain a constant header record which provides a meaningful word or phrase to identify each field. This will be validated each time your new business file is processed. If there is a mismatch between the supplied and expected headings, we might need to contact you to discuss the unexpected change. Page 5 of 8

6 Data Quality Once the processing of your submission file becomes routine, we will not normally report data faults to you as this would increase the complexity of our business processes and both our operations. We will assume that any such faults are an artifact of your internal processes. In our experience, low data quality increases the complexity of systems while decreasing their ability to manipulate data in useful and productive ways. We believe data quality improvements are best done at source. APPROPRIATE USE OF FIELDS Each field should have a single use and ideally should not contain unrelated data. For example, the four address fields should not contain a postcode or country name. PEOPLE'S NAMES The name fields: title, first, middle, and last should relate to a single person and not to a couple who may be jointly responsible for a debt. Jointly assigned debts should be presented as two accounts contiguous within the submission file. TELEPHONE NUMBERS Ideally, telephone number fields should contain just that. If there is no telephone number then the field should be blank. If a number is supplied, then it should have the exchange code and the subscriber number. If the number is ex-uk then the country dialing code (from the UK) should be supplied using double zero or plus-sign followed by the country code. Multiple Debt Debtors A multiple debt debtor is where the debtor has two or more unpaid invoices perhaps for unrelated products or services, and you want to instruct us to collect on all of them at the same time. In these cases there should be a mechanism in place to identify the individual debtor in addition to your reference number for each individual unpaid invoice. DEBTOR'S ACCOUNT IDENTIFIER This will be an account number, customer id, or membership no. that identifies the person or company - and not necessarily the debt. This code will be unique to the person or company. DEBT REFERENCE NUMBER This will be an alphanumeric code which uniquely identifies a specific invoice or transaction that is to be collected. HOW WE WILL ORGANIZE THE INFORMATION We use two methods of organizing account information: Composite and Virtual. Composite Accounts This is our preferred account handling method. When you submit account information via a single file, we will combine the debts into one account on our system. The debtor's account identifier will be used as the primary key to access that data. Our collection effort will focus on collecting the whole amount as if it were a single debt. Virtual Accounts These are specifically designed for use by banks with high volume, high value debts. The virtual account is a composite account connected to one or more sub-accounts. Each sub-account assumes the identity of each bank account the customer has with the bank. Sub-accounts can be paid off in a prescribed order, accessed and reported separately. We can also handle ongoing bank interest charges and balance adjustments for each sub-account, including accounts that are in credit. Page 6 of 8

7 Joint Accounts Perhaps the most complex issue for submission files to handle is clearly communicating who the parties are to a joint account. If your operation does not deal with joint accounts, then please skip this section. Where a single debt is owed jointly by two or more parties, we strongly recommend that you supply a separate submission record for each party. Sometimes one party agrees to pay half, while the other refuses. Complex negotiations and pay-back arrangements are difficult to manage when a single database record attempts to represent two or more people. The following abstract submission file example shows how to express, using consecutive records, the idea that Mr and Mrs Smith are joint parties to the same account: Reference Title Last JointAccount Mr Jones Miss Brown Mr Smith Mrs Smith Mr Green Mrs White 0 In the following case, Mr and Mrs Smith and there friend Mr Green are all joint parties to a single account: Reference Title Last JointAccount Mr Jones Miss Brown Mr Smith Mrs Smith Mr Green Mrs White 0 Here, the JointAccount field determines which accounts are linked together by our system, not the reference number you supply. The first party must always precede the one or more second parties. All joint-party records, for the same account, must be contiguous. Further Support We hope this document provides enough information for you to develop your submission file. However, should you need further assistance we would be pleased to help. You may contact our I.T Department on The contact name can be found on the that this document was attached to. Page 7 of 8

8 APPENDIX A ASCII CHART WITH DECIMAL AND HEXADECIMAL VALUES Grayed out characters are not permitted anywhere in a submission file. Character codes not shown on this chart are also not permitted. Char Dec Hex Char Dec Hex Char Dec Hex Char Dec Hex (nul) 0 0x00 (sp) x40 ` 96 0x60 (soh) 1 0x01! 33 0x21 A 65 0x41 a 97 0x61 (stx) 2 0x02 " 34 0x22 B 66 0x42 b 98 0x62 (etx) 3 0x03 # 35 0x23 C 67 0x43 c 99 0x63 (eot) 4 0x04 $ 36 0x24 D 68 0x44 d 100 0x64 (enq) 5 0x05 % 37 0x25 E 69 0x45 e 101 0x65 (ack) 6 0x06 & 38 0x26 F 70 0x46 f 102 0x66 (bel) 7 0x07 ' 39 0x27 G 71 0x47 g 103 0x67 (bs) 8 0x08 ( 40 0x28 H 72 0x48 h 104 0x68 (ht) 9 0x09 ) 41 0x29 I 73 0x49 i 105 0x69 (nl) 10 0x0A * 42 0x2A J 74 0x4A j 106 0x6A (vt) 11 0x0B x2B K 75 0x4B k 107 0x6B (np) 12 0x0C, 44 0x2C L 76 0x4C l 108 0x6C (cr) 13 0x0D x2D M 77 0x4D m 109 0x6D (so) 14 0x0E. 46 0x2E N 78 0x4E n 110 0x6E (si) 15 0x0F / 47 0x2F O 79 0x4F o 111 0x6F (dle) 16 0x x30 P 80 0x50 p 112 0x70 (dc1) 17 0x x31 Q 81 0x51 q 113 0x71 (dc2) 18 0x x32 R 82 0x52 r 114 0x72 (dc3) 19 0x x33 S 83 0x53 s 115 0x73 (dc4) 20 0x x34 T 84 0x54 t 116 0x74 (nak) 21 0x x35 U 85 0x55 u 117 0x75 (syn) 22 0x x36 V 86 0x56 v 118 0x76 (etb) 23 0x x37 W 87 0x57 w 119 0x77 (can) 24 0x x38 X 88 0x58 x 120 0x78 (em) 25 0x x39 Y 89 0x59 y 121 0x79 (sub) 26 0x1A : 58 0x3A Z 90 0x5A z 122 0x7A (esc) 27 0x1B ; 59 0x3B [ 91 0x5B { 123 0x7B (fs) 28 0x1C < 60 0x3C \ 92 0x5C 124 0x7C (gs) 29 0x1D = 61 0x3D ] 93 0x5D } 125 0x7D (rs) 30 0x1E > 62 0x3E ^ 94 0x5E ~ 126 0x7E (us) 31 0x1F? 63 0x3F _ 95 0x5F (del) 127 0x7F Page 8 of 8