X9Utilities RCC
X9Utilities Remotely Created Checks (RCC) — can be implemented using X9Utilities “-write”. This tool has the capability to dynamically draw front and back images as an alternative to loading them from external image folder(s). This image drawing process is typically used in one of several flows:
- First is Remotely Created Checks (RCC), where production items are being created.
- Second is Test Center automation, where test items are being created.
- Third is usage to create electronic adjustment files, which can be targeted for production environments.
Specifically regarding RCCs, they are electronic items where the check images are dynamically created (drawn) and are not captured. Originated RCCs are debits to a specific customer bank account and require authorization of the account owner. RCCs do not bear the signature of account owner but instead include the account holder name within the image itself. The account holder can authorize the creation of the RCC in various means including in-person or telephone. Complete and accurate MICR line information for the customer account must be provided. RCCs are often created as an alternative to ACH by credit card companies or telemarketers. A benefit of RCCs are that they are cleared through the check image clearing networks and RCCs are processed through the check clearing networks and are governed by rules including the Uniform Commercial Code (UCC) and the Expedited Funds Availability Act (Regulation CC). Remotely Created Checks have the potential to be used in situations where ACH may not be available in a specific clearing scenario.
RCCs are similar to their check counterparts. They embody a paper instrument that contains an unconditional written order, instructing a drawee bank (paying bank) to make payment to the order of a designated payee and are processed through the banking system. They serve a useful business purpose in a diverse market, for applications such as Telephone Marketing, Bill Payments, Loan Repayments, Recurring Insurance Payments, and Internet payments.
FED Position as of January 2019 — Due Diligence Required
Per information from RemoteDepositCapture.com, the Federal Reserve appears to have closed the door on widespread adoption of ECIs, despite widespread industry support. The Fed adopted an amendment to Regulation J in November 2018 (the rule set that governs the collection of checks and other items through Reserve Banks) that effectively bans financial institutions from clearing electronically-created items (ECIs) through the Reserve Bank System which became effective January 1, 2019.
The Fed in explaining its decision said ECIs do not fit Uniform Commercial Code (UCC) and regulatory definitions of checks since they never exist in paper form. It also said that its decision to ban ECIs from the Reserve Bank System would not stop banks from agreeing to clear ECIs between one another. However, since a significant share of checks clear through the Reserve Bank System – 45 percent on the forward collection side and 68 percent of returns, according to the Fed’s data – most experts expect FIs will not encourage business clients to use ECIs in lieu of issuing paper checks.
RCC Items Should be Assigned RPC “6”
As defined in X9 Standard X9.100-160-2014, the EPC is a MICR digit that conveys special information regarding the correct handling or routing of a check or check data to financial institutions and other processors The EPC field is MICR field 6, position 44 on the MICR line, and is located to the immediate left of the Routing number.
A new EPC code of “6” was added to the latest revision of the X9 Standard Magnetic Ink Printing (MICR) X9.100-160-2014 Part 2. Per this standard, the EPC code of “6” shall be assigned when RCC items are created by their originator. This new code, when used appropriately, will create a mechanism for identifying and monitoring these items.
Our RCC Support Leverages “-write” Functionality
The overall process to create an RCC image file is very similar to creating any other x9.37 file. The only significant difference is that images are dynamically drawn and are not loaded from externally supplied image folders. When drawing images, the “imageFolder” and “image” directives typically used by “write” are not applicable since images will not be loaded from external TIFF files. Several new directives are added in their place which provide the information that is required to draw the front and back item images. All other write functionality remains in place and can be leveraged by RCC file creation. This is a tremendous advantage since this common approach allows XML parameters to be provided which control all aspects of the x9.37 file creation process.
Using Image Templates
RCC files will not import images to be attached to each item, but must instead draw them. X9Utilities includes several image templates which can be either used directly or as the basis to build your own customized templates. These standard templates are:
- “rcc1” which is a basic RCC template.
- “rcc2” which is a more complex RCC template that supports the insertion of additional text fields and demonstrates the full range of all capabilities.
- “credit” which is a generic credit document that might be used for internal adjustments.
- “debit” which is a generic credit document that might be used for internal adjustments.
- “testDoc1” which is a test document and is clearly marked as such.
Most usage of our RCC functionality will not want to use our predefined templates but will instead want to define their own custom formats.
- You may have one or more RCC templates
- Each X9Utilies processing run may utilize one more templates within the run
- Templates allow you to position text at the appropriate location based on your design
- Text will be drawn using the font and size of your choosing
Drawing RCC Images
Write has the additional capability to dynamically draw front and back images as an alternative to loading them from your external image folder(s). Images are drawn from a front image template of your design that is used as a background to construct each individual image. Templates are typically drawn using common tools such as GIMP, Paint, or Photoshop and are saved in a format such as PNG to our internally defined image folder. Each template consists of a series of internally defined fields which can be placed anywhere within the image based on your template design. These fields can also be drawn with a font and font size of your choosing. These definitions are applied to the “templates.xml” configuration file which is dynamically loaded by the SDK during startup.
Back side images can be created in several manners. This can be a template image of your design, where a variable number endorsement lines are then added. This can alternatively be an image that includes a paid stamp, a variable number of endorsement text lines, and an optional group of “sign here” lines that simulate that area on the back side of a typical check. Finally, for testing environment, the paid stamp can be replaced with a document identifier which can be used to display the internal document type for this item (GL, Cash Ticket, Batch Ticket, etc).
RCC creation has two new CSV line types that are unique to image drawing:
| Line Type | Column | Content | Description |
|---|---|---|---|
| Image Creator Definition | 1 | “imageCreator” | Sets values for image creator date and time. |
| 2 | Image creator routing number | Identifies the image creator routing number and is populated in field 50.03. If this value is not specified, it will first be defaulted first from field “itemImageCreatorRouting” and then secondly from field “cashLetterEceInstitutionRouting”. | |
| 3 | Image creator date | Identifies the image creator date and is populated in field 50.04. If this value is not specified, it is defaulted from field “createDate”. | |
| Draw Image Definition | 1 | “drawImage” | Identifies this as a draw image row which must be present for each item. |
| 2 | Front image template name | Identifies the template name to be used for drawing. This template must be defined in the “images” folder and then also must have a definition in “checkFormats.xml” which describes the coordinates of specific fields within the image. | |
| 3 | Back image template name | Identifies the back-side image to be used; this is optional and will be automatically drawn when omitted. When this image is provided, it should have the same physical size as the front image. Several special values are also available: • “blank” will insert an empty image. • “/identifier” will draw the supplied text on the back side image as document identification. For example “/GL Ticket” will draw identify the item as GL. • “/$identifier” will draw the supplied text on the back side image as document identification, and also includes a signing block on the far right side of the image. • “/#” will draw a paid endorsement stamp on the back side image. Sign here text can be included by using “/$#”. The endorsement stamp includes a series of text fields that are shown within the paid stamp. The first is border text that will be outline the borders. This is followed by heading lines which are shown in a larger font, followed by transaction lines which are shown in a smaller font. One or more blank lines identify the break between heading and transaction lines. A sample is as follows: “/$#Company Name,For Deposit Only,Additional Comments,Account 1234567890,,Store 187,,Transaction ID 144929”. | |
| 4 | Item identifier | Front side image field. | |
| 5 | Date written | Front side image field. | |
| 6 | Address line 1 | Front side image field. | |
| 7 | Address line 2 | Front side image field. | |
| 8 | Address line 3 | Front side image field. | |
| 9 | Address line 4 | Front side image field. | |
| 10 | Address line 5 | Front side image field. | |
| 11 | Payee line 1 | Front side image field. | |
| 12 | Payee line 2 | Front side image field. | |
| 13 | Payee line 3 | Front side image field. | |
| 14 | Memo line | Front side image field. | |
| 15 | Bank name | Front side image field. | |
| 16 | Signature line | Front side image field. | |
| Lastly | One or more endorsement lines, each presented in subsequent columns. | Back side image. Each text field is prefixed with “/E/” for identification. For example, an example might be “/E/Remote Deposit ISN 8849243”. These text lines are inserted into the image and can be used for a variety of application specific purposes. For production files, they can be used as a multi-line endorsement. For test files, they can contain alternate information such as expected results or special instructions. |
RCC Examples
RCC files will not import images to be attached to each item, but must instead draw them. Most RCC applications will only create debits, but this facility is capable of creating both debits and credits. This example includes both an endorsment stamp and endorsement lines on the first item. The second item includes a sign here block and endorsement text lines. An example of a CSV to dynamically create images (which includes BOFD addendums) is as follows:
“headerXml”,”c:/users/x9ware5/documents/x9_assist/rcctesting/headers8.xml”
imageCreator,123456780,20210401
credit,20006,44000001,555555550,”1234567890123/”,123456,
drawImages,credit,”/$”,”123A55001″,20140806,”John Doe”,”1234 Main Circle Dr”,”Springfield, St 88888-9999″,,,”Payee line 1″,”Payee line 2″,”Payee line 3″,”Memo line here”,”Bank name here”,”Signature line here”,”/E/Endorsement line 1″,”/E/Endorsement line 2″
t25,10002,44000002,087770706,29602722/5526,,6
drawImages,debit,”/$”,”123A55001″,20140806,”John Doe”,”1234 Main Circle Dr”,”Springfield, St 88888-9999″,,,”Payee line 1″,”Payee line 2″,”Payee line 3″,”Memo line here”,”Bank name here”,”Signature line here”,”/E/Endorsement line 1″,”/E/Endorsement line 2″
t25,10004,44000003,087770706,29602744/5527,,6
drawImages,debit,”/$”,”123A55002″,20140806,”John Doe”,”23456 Main Circle Dr”,”Springfield, St 88888-9999″,,,”Payee line 1″,”Payee line 2″,”Payee line 3″,”Memo line here”,”Bank name here”,”Signature line here”,”/E/Endorsement line 1″,”/E/Endorsement line 2″
end
X9Utilities Draw
Draw reads a CSV file and then writes tiff images, as is provided as a companion tool to -write. The writer function embeds dynamically drawn images directly into the x9.37 file that is being constructed, while draw can be used to create those images and directly save them to external tiff files, instead of inserting them into the type 52 records. Draw can be used to create single page tiff’s for the front-back images, but can also be used to create multi-page tiff images, which will be a single tiff image that contains both the front and back within a single image file.
Command line options
| Switch | Description |
| -dpi: | Assigns the output image dpi used to draw images, with a default of 240. Assigned values must be either 200 or 240. |
| -l | Will list all incoming csv lines to the log. |
| -batch | Invokes batch (folder based processing; see that earlier topic for more information. |
| -workUnit: | Assigns command line parameters and files from an xml file that was previously created and saved by the X9Utilities facility within X9Assist. This allows you to easily repeat an X9Assist task directly in X9Utilities batch. |
Draw csv line types
| Switch | Description |
| imageFolder | Defines the folder used to load template images that are referenced when drawing images from pre-constructed templates. The folder name is provided as the second parameter, and typically would always be enclosed in quotes since it may contain embedded blanks. |
| outputFolder | Defines an optional high level folder to be used when writing the output images. This line is not needed when the output image file names are fully qualified. The output folder name can be changed as often as desired. The folder name is provided as the second parameter, and typically would always be enclosed in quotes since it may contain embedded blanks. |
| paidStamp | Defines a paid stamp to be applied to back-side images. The paid stamp is optional and can appear as often as needed within the csv file, and must appear before the items to which it applies. The paid stamp can appear as often as needed within the csv file, even at the item level. |
| item | Provided information about each logical item to be drawn. Columns are as follows: Auxiliary OnUs External Processing Code (EPC) Routing OnUs Amount Identifier (any string you desire; for example the item sequence number) Front image file name Back image file name. This file name can be defined as “omit”, which means that the back side image will not be created. It can also be defined as “multi”, which means that a multi-page tiff image is to be created that contains the front and back side images within a single tiff file. |
| drawImages | Provides information for the two images that are to be drawn. Refer to the -write function for documentation and usage. |