IntelleDoc Solutions Getting Started Guide
CSi IntelleDoc Solutions™ Overview
The CSi IntelleDoc Solutions™ are software compliance components that address the demanding documentation requirements inherent in financial transactions. Blending dynamic and static document technologies with guaranteed compliance and flexible technological architecture, CSi IntelleDoc Solutions™ create competitive differentiators that CSi customers and business partners can leverage in an increasingly competitive market.
CSi IntelleDoc Solutions™ consist of a suite of compliance components designed to work together as an intelligent system to deliver accurate transaction documentation unlike any other solution on the market today.
CSi IntelleDoc Document Libraries contain built-in intelligence and leverage dynamic technologies to assemble documents containing only the relevant information about the transaction, customer, and institution. The results are documents tailored to the transaction that are easier to read and understand.
Document Selection Logic (DSL) selects the documents required for a given financial transaction type and produces a list of documents that CSi warrants as accurate. The list is the minimum set of documents necessary, including the quantity of each document, for a compliant transaction based on state and federal laws as well as industry standards.
Transaction Manager Suite is a multi-tier .NET Remoting application that provides document selection and document rendering. Support includes the rendering of multiple documents in a single request as well as “full transaction” requests, where document selection and document rendering occurs together. Platforms systems may integrate with the Transaction Manager at one of three levels:
Transaction Server is a .NET class library that provides integration at the lowest level. It is best suited for thick-client environments where the document selection and rendering software is installed on end-user workstations. It can also be used in server environment where the platform system controls load balancing. The application that integrates with the Transaction Server must run in Microsoft’s .NET runtime environment.
Transaction Runner is a .NET class library that uses .NET remoting to handle requests to one or more Transaction Server instances. A platform system running on a server integrates directly with the Transaction Runner, which can handle requests asynchronously, it handles load balancing, and provides redundancy to improve fault tolerance. The application that integrates with the Transaction Runner must run in Microsoft’s .NET runtime environment.
Compliance Service is a web service application that uses a SOAP interface to provide access to the Transaction Runner via the Internet or an intranet. It handles load balancing, and provides redundancy to improve fault tolerance. Integration via the Compliance Service is best suited for platform systems that do not run in a Microsoft Windows environment.
IntelleDoc Viewer Control is a .NET user control that supports document viewing and on-screen data entry.
Custom Document Editor is an application dedicated to the design of custom documents. Custom documents may be based on existing PDF documents, image files, or may be created from scratch.
IntelleDoc Advisor is an application used to modify transaction data values in order to assess changes in document rendering. It supports .NET CSi IntelleDoc Solutions file formats.
IntelleDoc Visualizer is an application used to validate the content of CSi TXL data files structured on the CSi Data Schema. It allows transaction data in a TXL file to be checked against a schema file, flagging data that does not comply with parameters of the schema so that it may be corrected.
Licensing CSi IntelleDoc Solutions™ Products
CSi IntelleDoc Solutions™ license keys are used to provide access to the functionality the financial institution has licensed from CSi.
All financial institutions receive a single license key for all CSi IntelleDoc Solutions™ products. This includes Custom Document Editor, the Transaction Manager suite, Compliance Services, IntelleDoc Viewer Control, CSi Simplicity, and documents.
A CSi IntelleDoc Solutions™ license key contains an encoding string of the following attributes: CSi Custom Number, CSi Customer name, Expiration Date, Document Sets Licensed, Custom Institution Type, Simplicity, CDE, IntelleDoc SDK and all properties associated with each attribute listed before.
The license key can vary in length due to its dynamic structure. The previous key (V2) ranges from 90 to 200 characters. The new key (V3) ranges from 350 to 500 or sometimes more characters. For storage purposes, a length less than one database page is sufficient for the license keys. For example, in SQL server the size of database page without header is about 8kb.
Updates
License keys expire on a predetermined date. CSi will contact the financial institution to provide a new license key in advance of that date to ensure that there is no interruption in product access. In the event that a financial institution adds or subtracts products, it will be issued a new license key by CSi.
Integration
CSi business partners need to store only a single license key per financial institution. The financial institution’s license key must be passed to the IntelleDoc Viewer Control and Transaction Manager integration point (Transaction Server/Transaction Runner/Compliance Service) for each document selection or rendering. This is critical as the license key holds the financial institution’s Institution Type (i.e., bank, mortgage bank, savings & loan, etc.). Failure to pass the correct financial institution’s personal license key can result in incorrect document selection.
Custom Document Editor
If the Custom Document Editor is not provided a license key, it defaults to Lite mode. A limited set of functionality is available in Lite mode. In addition, only Custom Document Editor Lite documents can be created and edited in Lite mode. The license key to enable a fully functional Custom Document Editor may be entered in the Preferences dialog box (Edit > Preferences > General). The license key string may also be added programmatically through the Custom Document Editor configuration file.
Transaction Data
In the CSi IntelleDoc Solutions™, transaction data may be defined using a unique blueprint for documenting transactions and dictates distinct processes for integrating data management structures.
CSi Data Schema Model
The CSi data schema is an XML-based data structure that provides a flexible and robust method for data communication between systems. A single data schema is used for Deposit, IRA, Consumer Lending, Commercial Lending, and Mortgage transactions. The result is a single data set, based on a single standard, that defines all transactions across multiple channels of customer contact. The CSi data schema model offers several practical advantages.
Offers great flexibility in its implementation and its ability to adapt to new industry standards.
Easily extensible when new product lines are added. The schema supports reuse of existing data structures and minimizes the development effort required to bring new products to market.
Efficient in its organization and in its ability to serve both single and multiple platform environments that are called upon to process high volumes of data.
Intuitive in its use by financial industry professionals who need to leverage their existing knowledge of transactions rather than learn cumbersome new technical jargon.
CSi Data Schema Organization
The CSi Data Schema is designed to mirror the natural manner in which financial professionals understand and process transactions.
In any transaction, there are general information requirements that must be satisfied in order for the transaction to proceed.
Parties participating in the transaction must be identified. This includes all external parties as well as parties associated with the financial institution.
Decisions must be made to determine if the transaction may proceed. Loan and deposit decision protocols are predicated on the transaction-relevant characteristics of the parties identified.
If the transaction involves an extension of credit, required collateral must be identified. Information specific to the type of collateral involved and the role it serves in the transaction helps minimize risk and allows lending business to be managed successfully.
Terms and provisions defining the financial institution’s product must be observed. These product definitions determine the specific parameters of individual transactions.
Federal and state regulations governing the transaction must be satisfied. Compliance with regulatory mandates is critical to the financial institution’s risk management strategy.
Data driving document selection must be defined. Certain data generated from transaction-specific criteria impact the type and of documents required to perfect the transaction.
General, corporate-level policies regarding transaction documentation must be fulfilled. These policies are not unique to a given transaction, but are specific to the financial institution and determined outside of the transaction context.
The CSi Data Schema has seven categories at its top level, which reflect these seven real-world categories. This structure places its focus on the data required for transactions rather than on the documents that will eventually accommodate that data. As a result, the CSi Data Schema helps developers better understand when data is in play and allows data to be mapped more easily.
Helper Applications
Helper applications are tools that provide additional functionality not available in the Transaction Manager suite.
Custom Document Editor
Custom Document Editor is a CSi IntelleDocs Solutions^TM^ application dedicated to the creation of custom documents based on existing CSi ocuments, PDF documents, image files, or blank documents. It offers a rich visual environment for designing financial forms with the sophisticated and unique visual identity required by individual financial institutions.
Refer to the Custom Document Editor User Guide for additional information.
IntelleDoc Advisor
IntelleDoc Advisor is an application used to modify data values in order to assess changes in document rendering. It supports CSi IntelleDoc Solutions DXL and FXL file formats. IntelleDoc Advisor provides a convenient environment for viewing datapoint information as it will appear on documents, allowing accurate evaluations to be made regarding structure of both documents and data files.
Refer to the IntelleDoc Advisor User Guide for additional information.
IntelleDoc Visualizer
IntelleDoc Visualizer is an application used to validate the content of CSi TXL data files structured on the CSi Data Schema. It allows transaction data in a TXL file to be checked against a schema file, flagging data that does not comply with parameters of the schema so that it may be corrected. The primary purpose of IntelleDoc Visualizer is to test TXL files for use in document selection and document rendering. Validation of the CSi Data Schema is a secondary benefit.
IntelleDoc Visualizer also allows the TXL data file to be exercised against the Transaction Server, CSi’s component for selecting, assembling, and outputting transaction documents. A copy of the Transaction Server component is embedded within IntelleDoc Visualizer.
Refer to the IntelleDoc Visualizer User Guide for additional information.
Understanding Documents
CSi IntelleDoc technology creates different types of electronic documents, or eDocs, that can be viewed on screen and printed.
Static IntelleDocs use fixed text. The only data that changes is the transaction-specific input for the datapoints included in the documents. The static text and layout of these documents does not change based on data input.
The content of dynamic IntelleDocs varies based on the data values that are provided. Blocks of content may be included or excluded based on the values of one or more datapoints.
Datapoints
Datapoints are variable data placeholders used to populate a document. Datapoints may have an associated data type for data validation. The majority of CSi datapoints are mapped to a node in the CSi Data Schema, and values can be provided via the schema instead of as a key/value pair.
Datapoint names are not case sensitive, but datapoint values are case sensitive. For example, the datapoint names C_GNL_ADDR_INST_InstitutionCity and c_gnl_addr_inst_institutioncity are recognized as the same datapoint by CSi software. However, the datapoint values A1 and a1 are recognized as different values by CSi software.
CSi Datapoint Naming Conventions
Datapoints are named based on succeeding levels of Division, Group, Category, Section and Description. Each level is separated by an _ (underscore). Each level follows a standard abbreviation convention that communicates its identifying information.
Example: C_GNL_ADDR_INST_InstitutionCity
| Level | Identifier |
|---|---|
| Division (1 character) | The division level represents the highest level product grouping to which the data is applicable. C – Common. Applicable if data may be used for all products (Deposit, Lending, and Tax Deferred Accounts) D – Deposit. Used exclusively for data appearing only in Deposit products. L - Lending. Used exclusively for data appearing only in Lending products (Consumer, Commercial, or Mortgage). I – TFA. Used exclusively for data appearing only in TFA products. _ No Identifier indicates a calculated field |
| Group (3 characters) | The group level represents the product usage within each division. CML - Commercial CNS - Consumer GNL – General GOV – Government SEL – Document Selection |
| Category (4 characters) | The category level represents the primary nature or type of data as which the datapoint is classified. |
| Custom: CTOM - Custom Field |
|
| Product: ACCT - Account Information ADDL - Additional Information ADDR - Address BSNE - Business Entity Information BUSN - Business Information CLLT - Collateral Information CLON - Collateral Co-owner |
|
| Section (4 characters) | The section level represents a secondary or additional layer of information descriptive of the nature or type of data the datapoint is classified as. Section is supplemental to the category selected. |
| Workflow: XSIM – Simplicity Workflow TFAW – TFA Workflow DEPW – Deposit Workflow LNDW– Lending Workflow PMTW– Payment Calculation Workflow |
|
| Custom: CTOM - Custom Field SPRT - Support (Custom) Information |
|
| Product: ADDR - Address ADTL - Additional Information AGRI - Agricultural BENE - Beneficiary Information BORR - Borrower Information BSNE - Business Entity Information BUSN - Business Information CALC - Sherman Calculations only CARD - Access/Debit/Credit Card CDIS - Closing Disclosure CESA - ESA Agreement Provisions CLLT - Collateral CLON - Collateral Co-owner COSN - Co-signer Information DATA - Administrative Data DATE - Date DEPR - Depositor Information FDCY - Fiduciary Information GFES - Good Faith Estimate Information GUAR - Guarantor Information HSAX - HAS Agreement Provisions HUDI - HUD Information HYPO - Hypothecator Information INDV - Individual Information INST - Institution Information INSU - Insurance Information |
|
| Description (unlimited characters; word breaks designated by uppercase letter; no spaces) | Example: FirstSecondThirdWord |
General Datapoint Naming Conventions
Datapoint names can consist of the following characters:
letters
numbers
dash (-)
underscore (_)
period (.)
Datapoint names must not begin with a period (.). Two periods insuccession (..) are not allowed anywhere in a datapoint name.
CSi recommends that partners using custom datapoint names begin those names with a company abbreviation prefix to avoid namespace conflicts.
Datapoint names beginning with underscore (_) are reserved for CSi datapoint names.
Datapoint Usage Types
All datapoints have an associated usage type that identifies when its data is required or optional. A form may be considered complete or incomplete based on data supplied to its datapoints. Additionally, a form may or may not render based on data supplied to its datapoints.
An in-play datapoint is one that is required in order for a document to be considered complete. In order for a form to be considered complete, all in-play datapoints must be supplied. As data is supplied to a document to satisfy initial datapoints and its form logic is executed, additional datapoints may be required for the form to render or be considered complete. The in-play datapoints for a given document may thus evolve as the document is being completed.
| Usage type | Description |
|---|---|
| structural_required | The datapoint is required to render the document. If such a datapoint is not supplied, CSi IntelleDoc Solutions™ does not render the document and reports that a value for the datapoint must be supplied. |
| structural_conditional | The datapoint may be required, depending on the values supplied for one or more other datapoints. If such an in-play datapoint is not supplied, CSi IntelleDoc Solutions™ does not render the document and reports that a value for the datapoint must be supplied. Once a structural_conditional datapoint is put in-play, it is considered structural_required. |
| structural_optional | Identifies datapoints that are not required, but affect the structure and/or content of the form if values are supplied. |
| data_required | The datapoint is required in order for the document to be legally compliant. If such a datapoint is not supplied, CSi IntelleDoc Solutions™ renders the document and places the warning message Form must be completed as a watermark on the top of the document. |
| data_conditional | The datapoint may be required, depending on the values supplied for one or more other datapoints. If such an in-play datapoint is not supplied, CSi IntelleDoc Solutions™ renders the document and places the warning message Form must be completed as a watermark on the top of the document. Once a data_conditional datapoint is put in-play, it is considered data_required. |
| optional | The datapoint is not required. If a value is supplied, CSi IntelleDoc Solutions™ includes this value in the document. If no value is supplied, CSi IntelleDoc Solutions™ renders the document with no warning or error messages. |
Rendering Forms
In order for a form to render, all structural datapoints that are in play must be supplied.
Completing Forms
In order for a form to be complete, all structural and data datapoints that are in play must be supplied to the Compliance Engine. If such datapoints are missing, the warning message Form must be completed appears as a watermark on the top of the rendered document.
Datapoint Formats
| Name | Format | Description/Example |
|---|---|---|
| alphadate | Month dd, Year | January 1, Two Thousand and Two |
| alphadollar | Two Thousand Four Hundred Fifty-seven and 35⁄100 Dollars | |
| alphamonth | Month dd, yyyy | January 1, 2002 |
| alphanumber | four | |
| alphaordinal | fourth | |
| alphapercent | five and one quarter percent (5.25%) | |
| alphapercentagepoints | five and one quarter percentage points (5.25%) | |
| canadian-post | XXX XXX | A1A 2B2 |
| capitalize | ALL UPPERCASE | ALL UPPERCASE |
| dollar | XX,XXX,XXX.XX | 100,000.12 |
| dollarroundup | XXX,XXX,XXX | If data entered is = 4567.56, expected display = 4,568 |
| If data entered is = 4567.49, expected display = 4,568 | ||
| dollarrounddown | XXX,XXX,XXX | If data entered is = 4567.56, expected display = 4,567 |
| If data entered is = 4567.49, expected display = 4,567 | ||
| dollarroundnearest | XXX,XXX,XXX | If data entered is = 4567.56, expected display = 4,568 |
| If data entered is = 4567.49, expected display = 4,567 | ||
| exactpercent | XX.XXXXXXXX | 18.125375 |
| fourdecimaldown | X.XXXX | 1.2345 (assuming 1.23456) |
| fourdecimalround | X.XXXX | 1.2346 (assuming 1.23456) |
| fourdecimalup | X.XXXX | 1.2346 (assuming 1.23456) |
| mm dd yyyy | mm dd yyyy | 1 01 2002 |
| mm/dd/yyyy | mm/dd/yyyy | 1/01/2002 |
| mmm dd, yyyy | mmm dd, yyyy | Jan 01, 2002 |
| mmm. d, yyyy | mmm. d, yyyy | Jan. 1, 2002 |
| mmm. dd, yyyy | mmm. dd yyyy | Jan. 01, 2002 |
| noformat | This format allows users to override default phone or Tax ID number and SSN format in the data dictionary. For example, (248) 123-4567 ext. 268. | |
| notarydate | Day of Month, yyyy | First day of January, 2002 |
| notarydatenumericday | 1st day of January, 2002 | |
| number | XXX,XXX,XXX | 123,456,789 |
| numericordinal | 4th | |
| odometer | XX,XXX,XXX.X | 100,000.3 |
| percent | XX.XXXX | 18.125 |
| phone | (XXX)XXX-XXXX | (800)123-4567123-4567 |
| ssn | XXX-XX-XXXX | 123-45-6789 |
| tid | XX-XXXXXXX | 12-3456789 |
| tin | XXX-XX-XXXX | 12-3456789 |
| yieldpercent | XX.XX | 18.01 |
| zip | XXXXX-XXXX | 1234512345-6789 |
Suffixed Datapoints
Some datapoints can be suffixed, allowing a single datapoint name to reference multiple values. A realized datapoint name is one that has been populated with suffix data values. Suffixed datapoints have a format of datapointName.i, where .i represents an unrealized suffix: one that has not been populated with suffix data values. The .i is a placeholder for a suffix value that has not yet been identified. For example, EntityId.1 and EntityId.2 can each hold a different entity ID value. If a suffixed datapoint has no value, it does not render. Some datapoints have multiple suffix levels, which behave similar to a multidimensional array. For example, a datapoint with three suffix levels has a format of datapointName.i.j.k.
Embedded Datapoints and Character Attributes
Certain character attributes may be embedded with the data in a datapoint or with the static text labels within a fixed text overlay field. Attributes may be combined in any sequence as long as an attribute’s tag pairing is maintained.
| Attribute | Tag | Example | Output |
|---|---|---|---|
| Datapoint insertion | <datapoint name=“dp”/> | Today’s date: <datapoint name=“date_datapoint” /> | Today’s date: January 1, 2006. |
| Bold | <bold> </bold> | The <bold>lazy</bold> dog. | The lazy dog. |
| Italics | <ital> </ital> | The <ital>lazy</ital> dog. | The lazy dog. |
| Strikeout | <strike> </strike> | The <strike>lazy</strike> dog. | The |
| Subscript | <sub> </sub> | The <sub>lazy</sub> dog. | The ~lazy~ dog. |
| Superscript | <super> </super> | The <super>lazy</super> dog. | The ^lazy^ dog. |
| Underline | <under> </under> | The <under>lazy</under> dog. | The lazy dog. |
| New line | <printline/> | The lazy dog.<printline/>The quick fox. | The lazy dog. The quick fox. |
| Tab | <tab/> | <tab/>The lazy dog. | The lazy dog. |
Predefined Datapoints
Datapoints that begin with an underscore ( _ ) are reserved for use by CSi and are referred to as predefined datapoints. If datapoints begin with an underscore, but are not included on CSi’s predefined datapoint list, they are ignored. These datapoints are not returned by the Compliance Engine as in play.
CSi IntelleDoc Solutions™ Files
A combination of data files contain the information necessary to fully process a document with the Compliance Engine.
FXL Document Files
FXL is the file format used by an IntelleDoc file. It is an encrypted XML file that contains document content, content selection logic, and associated content metadata. It also includes data-processing logic for selecting documents and additional selection metadata. They perform two types of selection:
Document selection. FXL files may be used to generate a list of documents required to perfect a transaction.
Content selection. FXL files may be used to generate the text content of a document.
Multiple FXL files can be chained together in the Compliance Engine to enhance functionality. For example, partner and institution document-selection customization may be handled by chaining additional partner-specific and institution-specific FXL files behind a generic/general document selection FXL file.
OXL Overlay Files
OXL is the file format used by overlay files. It uses XML to store overlay information. It is an optional file used only whe customizations have been added to an FXL file. See Appendix B for more information on OXL file structure and schema.
OXL files contain overlays. An overlay is a field used to add additional elements to a CSi document. The element can be:
fixed text - static text that displays in the same way every time the document is used. Fixed text overlays may also hold datapoints inserted into the static text.
mergable text - data from any single datapoint that you define for the field.
images - contains a datapoint that specifies an image that is used for display in the field.
graphic shapes used to format the document or increase its readability. These can be lines, rectangles, or circular shapes.
DXL Data Files
DXL is the file format for an eDoc data file. It is an XML file that supplies to the Compliance Engine data values along with the associated layout directives for values that are displayed. Data values that are displayed on an eDoc form may have a number of corresponding attributes that dictate their display characteristics. See Appendix C for more information.
The DXL format uses key/value pairs to present transaction data defined with a common data dictionary. Generally, a DXL file corresponds to a single IntelleDoc.
TXL Data Files
TXL is the data file format modeled on the CSi Data Schema. TXL is an XML file that supplies all of the information necessary to document a given transaction and may require multiple IntelleDocs to contain and present that information. Value elements in the TXL file may have a number of corresponding attributes that dictate their display characteristics.
MXL Script Files
MXL is the file format used by script files. It uses XML to store script information that manipulates and maps datapoint values before they are applied to a customized form. Such scripts may be created or modified in either Custom Document Editor and IntelleDoc Data Mapper. That scripting information can then be executed by the host.
A data manipulation script is a single script block containing a series of JavaScript statements that perform manipulation of input data values.
A data mapping script is a small script that is applied to a single CSi datapoint for the purpose of mapping its value to platform system data.
In addition to external MXL script files, script information may also be embedded in the FXL file with the rest of the form information.
Data scripts follow JavaScript standards. A global variable, dataValues, is available to the script, which provides access to Compliance Engine input data values. Input data values are supplied by the platform system to the CSi Compliance Engine.
Blank Datapoints
The IntelleDoc Viewer Control supports the use of blank datapoints in a document that are intended for completion later. For example, a notary datapoint may be left blank for later completion at another location. There may also be instances when the datapoint information is not know at the time that the document is rendered.
A blank field refers to a data/fill-in datapoint that is rendered on a dynamic document as a blank fill-in field. To designate a datapoint as a blank field, its value must be set to an empty string and its EmptyValue property must be set to blankField.
A blankable datapoint refers to a data/fill-in datapoint whose value may be empty without triggering the “form must be completed” margin message when EnableBlankFields is true.
Structural datapoints are not allowed to be blank, as they are required to render the document. The only datapoints that may be blank are:
data_required
data_conditional
optional
When blank fields are enabled, a non-zero blank field width allows space representing the blank datapoint to be rendered in the document. When a blank field width of zero is used, no space for the datapoint is rendered in the document. Blank fields are enabled with the BlankFields property.
The presentation of blank datapoints is managed in several locations, with an order of precedence determining if a blank datapoint is expressed in the document as a blank space.
| Location | Precedence (1 is highest) | Description |
|---|---|---|
| DXL file | 1 | emptyvalue attribute within the datavalue element. |
| TXL file | 1 | emptyvalue attribute within a leaf node. |
| FXL file | 2 | Cannot be modified. |
| Compliance Engine preferences | 3 | csi.Engine.Properties.Preferences class:using csi.Engine.Properties;…Preferences prefs = new Preferences( csiLicenseKey );prefs.FieldPrefs.EnableBlankFields = true;prefs.FieldPrefs.BlankHighlight = DataFieldPreferences.BlankHighlightType.gray30;// Not required, but helps readability of rendered document.prefs.FieldPrefs.RenderForDataCollection = true;… |
| Compliance Engine / IntelleDoc Viewer Control | 4 | BlankFields and BlankShading properties:csi.Controls.EDocView viewer = new csi.Controls.EDocView();…viewer.BlankFields = true;viewer.BlankFieldsShading = BlankFieldsShadingType.Underline;… |
The background color of blank datapoints is managed with the BlankFieldsShading property.