Credit++ Toolkit Version 5.1.0.8
Added support for TransUnion TUNA 2
The TransUnion Network Access system (TUNA) utilizes a client-side SSL certificate that is due to expire on March, 18th 2012.
TransUnion has sent alerts to its members with instructions on how to create, download and install a new client side SSL certificate.
Part of that process requires the member to create a SystemId and System Password. This new certificate must be installed before the
existing one expires.
IMPORTING THINGS TO KNOW ABOUT TUNA2 AND THE NEW TRANSUNION CERTIFICATE
- a) The New TUNA2 TransUnion site has a different URL
https://netaccess-test.transunion.com is the test URL for TUNA 2
https://netaccess.transunion.com is the production URL for TUNA 2
- b) The New TransUnion Certificate has no friendly name
The Credit++ Toolkit provides parameters to reference the certificate by its friendly name and look for it in a particular certificate store.
The existing certificate provided by TransUnion already contains a friendly name such as ‘TUNA Production Client Cert’.
The new certificates being provided by TransUnion do not contain a friendly name. Hence, you will need to edit the certificate after it is installed and add a friendly name.
Use that friendly name and the certificate store that it is install in (MY for personal, ROOT for trusted root) when using this new certificate.
Example:
oAcc.CommParm.Mode = "WEB"
oAcc.CommParm.Web.Certificate = TheFriendlyName
oAcc.CommParm.Web.CertificateStore = TheCertStore
- c) TransUnion will begin matching the certificate to the subscriber code
At some point in 2012, TransUnion will begin ‘tethering’ the new certificate to the subscriber code being used. No official date has been confirmed as to when that
Tethering will begin; nor has any documented response been offered from TransUnion regarding what error response will be returned.
In preparation for that inevitable change, Credit++ Toolkit version 5.1.0.8 now implements the required TransUnion TUNA2 XML wrapper when sending TUNA2 request to TransUnion.
CHANGES REQUIRED ON YOUR END
Currently TransUnion requires existing TUNA (TUNA1) credentials to appear in their CD01 segment. Although those credentials were never authenticated by TransUnion, they are required. Within the Toolkit, those parameters are set as follows:
oAcc.TUCParm.CustomerDataType = "05"
oAcc.TUCParm.CustomerDataCode = MyTUNALoginId
oAcc.TUCParm.CustomerDataPassword = MyTUNAPassword
TUNA2 requires the SystemId and System Password that you used when you created the TUNA2 certificate to appear in the TUNA2 XML wrapper. Within the Toolkit those parameters are set as follows:
oAcc.CommParm.Web.UserId = MyTUNALoginId ‘(SystemId from TUNA2 certificate creation process)
oAcc.CommParm.Web.Password = MyTUNAPassword ‘(SystemPassword from TUNA2 certificate creation process)
When the Credit++ Toolkit sees a value in either of these two parameters, the TUNA2 XML wrapper is created.
!HINT: The TUNA credentials used in TUNA1 are STILL REQUIRED. While they are not validated, TransUnion still expects those fields to be populated. They do not necessarily need to contain the TUNA2
credentials but must contains some non-blank value.
WHAT IF I DON’T MAKE THESE CHANGES
If you do not begin setting the oAcc.CommParm.Web.UserId and Password parameters, then the Credit++ Toolkit will not create the XML envelope. Our testing has determined that without the XML envelop,
TUNA2 will still return data. However, once ‘tethering’ is implemented by TransUnion, it will surely fail. Hence it is recommended that you begin making these changes as early as possible in 2012.
Corrected defect in Access Assistant causing IIS abend
A day-one defect has been reported and corrected in the Accessing Assistant in the thread handle management logic. While bureau data access was not affected, a random memory location was being corrupted when the Access Assistant was being normally terminated. In certain cases, this corruption caused an abend in Microsoft’s IIS7.
Adjusted all score factor texts to more precisely match bureau documented text
The score factor texts defined within the Credit++ Toolkit have previously been crafted to grammatically represent the factor reason codes rather than explicitly represent the text provided by the bureaus.
These factor texts have all been reviewed and modified to represent the exact text reported through bureau documentation.
Adjusted common reports’ Equifax Safescan/Identity Scan messages to more precisely match bureau documented text
Equifax is retiring its SAFESCAN alerts and replacing that feature with its new IDENTITY SCAN feature. The alert texts defined within the Credit++ Toolkit’s formatted reports has been updated to explicitly represent the exact texts provided by Equifax. In places where the codes between SafeScan and Identity Scan overlap, the Identity Scan verbiage is used.
Credit++ Toolkit Version 5.1
Version 5.1 of the Credit++ Toolkit has arrived!
This latest Toolkit release offers several new features as well as comprehensive additions to
assist institutions in complying with the upcoming consumer FCRA disclosure requirements.
The topics itemized below will present a brief introduction to all the enhancements and
extensions and provide links to the more detailed specifications of each Toolkit addition.
Dodd-Frank FCRA Amendments
There are several consumer disclosure requirements which are scheduled to take effect
July 21st, 2011. These amendments to the FCRA are included in the Dodd-Frank Wall Street
Reform and Consumer Protection Act.
These changes are still open for comment and the effective date of all the DFA provisions
have not been officially adopted. Regardless, we have implemented the additional Toolkit
changes necessary to support these new provisions.
Previously, in the November 2010 Release of Toolkit Version 5.0 (Consumer Score Disclosure Enhancements),
many relevant features where added supporting the Consumer Score Disclosure requirements concerning
Risk Based Pricing that took effect January 1st, 2011. Much of what was introduced at that time
has already prepared the Toolkit and users for compliance with these subsequent Dodd-Frank amendments.
The specific Consumer Score Disclosure enhancements presented in this Toolkit release are:
- Two additional built-in disclosure forms (FORMB6, FORMB7) which conform to the suggested content and layout contained in the FDA legislation.
- Support inquiry based options for adding CSD information to data responses from each credit bureau.
Finally, to help make any potential compliance testing for the new provisions of the Dodd-Frank FCRA amendments easier,
Luxor has updated the score factor verbiage for all FICO score models (including Equifax Beacon and TransUnion Empirica models)
to explicitly match the published documents from each credit bureau. Luxor previously employed factor text that was
semantically the same rather than identical in order to allow for uniform inter-bureau definitions.
Therefore, this is largely a cosmetic change, but one that may hasten the process of verifying compliance with DFA.
Fully Customizable Report Layouts
The Toolkit's Format Assistant now provides the ability to greatly customize the display of
printable credit reports. New report layouts can be created by modifying predefined templates
or built entirely from scratch.
There are currently eighteen major data sections which can be displayed in any desired sequence.
Further, most sections can be refined to include custom data selection criteria,
alternate sort orders and even subdivided into discrete groups with optional group headers.
The Report Customization chapter in the Help File includes detailed discussions on all the
available configuration features and how they are implemented.
A set of new interfaces has been added to facilitate the manipulation of report layout
templates. For developers, these can be referenced in the Help File's Format Assistant's
Classes chapters. A complete working programming example is also available in the Help File's
custom layout sample topic.
Expanded Report Layout Options
The effort to provide customizable reports has also allowed for the introduction of additional
report layout options. A new report type, called LUXREPORT, has been created which inherits
its styles from the existing LUXCOMMON and LUXLENDING reports.
Using this report type several new features can be activated:
The Summary sections can now be instructed to ignore any accounts which are currently
being disputed by the consumer or accounts on which the consumer is merely listed as an
Authorized User.
Summary displays can also be more discretely controlled. With the existing LUXCOMMON
report type only one Summary can be generated which contains aggregates for the entire report.
If the credit data represents a Joint credit bureau response, the Summary contains
totals of both consumers, leading some values possibly being counted twice.
The new PARTITIONS format option allows for Summary calculations specific to each consumer.
New Data Mining Capabilities
A long overdue extension has been added to the Judgment Assistant which leverages the
depth and flexibility of its ELSE syntax to quickly identify unique bureau elements and
data conditions. Using a new ELSE command, SELECT, criteria for semantically isolating
qualified data elements can be as simple or complex as business analysis requirements demand.
The instruction SELECT OPEN AUTO TRADELINE WHERE PAYMENTAMT > 500 would return all the
accounts which conform to those conditions. There are numerous specific field level comparisons
that ordinarily would have to be painstakingly developed to arrive at the desired result.
With these data mining extensions those comparisons are taken care of, regardless of the
credit bureau, so you can concentrate more on business logic, rules and objectives.
Learn more on how to start mining by visiting the Data Mining chapter in the Help File.
New Inquiry Options Interface
As the number of optional bureau products and services continues to grow, the associated interface for
selecting these options in the Access Assistant also becomes more complex. In order to help streamline the
fashion in which these settings are defined and populated, a new bureau parameters interface has been created.
Each bureau's parameters object now includes an InquiryOptions property.
This property accepts an option name to indicate which setting is being viewed or modified. This means that all
options can be more easily manipulated without having to hard code explicit references to unique values in bureau's
parameters list. This should help reduce the amount of code required to support all the possible options and
also Luxor to bring new bureau options to market faster. Review the Help File's Request Options chapter for links to
the bureau specific option settings.
This does mean that portions of the existing bureau parameters interface are now deprecated.
In future the InquiryOptions will be the mechanism for requested new bureau products or services.
For backwards compatibility reasons, these deprecated interfaces will still be supported.
For example, the existing boolean EFXParm.OnlineDirectory property can be replaced by a simple "OnlineDirectory"
reference in the EFXParm.InquiryOptions property, as in:
oAcc.EFXParm.InquiryOptions("OnlineDirectory") = "Y" instead of oAcc.EFXParm.OnlineDirectory = True
Equifax Additions
In Equifax, we have added support for the Safescan replacement service called Identity Scan.
This includes updating the verbiage corresponding various alert codes as well as being able to parse and display
results contained in the new Identity Scan (IS) segment.
The definitions for the new VantageScore 2.0 scoring model have also been added.
Experian Additions
In addition to all Consumer Score Disclosure related changes, the definitions for the new VantageScore 2.0
scoring model have been incorporated into the Toolkit.
TransUnion Additions
In addition to all Consumer Score Disclosure related changes, the definitions for the new VantageScore 2.0
scoring model have been incorporated into the Toolkit.
Credit++ Toolkit Version 5.0.19
Risk Based Pricing
The Credit++ Toolkit now has complete support for the new Risk Based Pricing regulations which were
recently added to the Fair Credit Reporting Act and take effect on January 1st, 2011. The regulations
mandate that consumers be notified when they have received less than favorable credit terms due to
a less than perfect credit bureau score. This disclosure notification is to include the actual credit
score and three additional data elements about the specific scoring model(s) used in the credit grantor's
decision process: the minumum possible score for each model, the maximum possible score and how
the consumer's score ranks as compared to the general population.
The Toolkit makes these additional values available in three new fields, MINSCORE, MAXSCORE and
PERCENTILE. The fields are populated dynamically through internal references to each credit bureau's
score distribution tables. Using these internal references means no extra coding or setup with each credit
bureau will be needed to have this data available.
Finally, the Format Assistant has new functionality for creating the required disclosure forms. With just a
couple new simple instructions, any of the five variations of disclosure forms can be generated to ensure
compliance with the new FCRA regulations.
Risk Based Pricing Support will enable you to:
- Retrieve minimum, maximum scores and consumer's percentile for any supported bureau score.
- Generate any of eight standard Risk Based Pricing disclosure letters.
Credit++ Toolkit Version 5.0
Featuring Luxor's Attribute Factory
Version 5.0 now includes over 1,600 credit data attributes.
Luxor’s Credit++ Toolkit features a newly updated Judgment Assistant that brings in-depth analysis
to your application. In a fraction of a second, your lending application can make a decision based upon
a comprehensive set of credit data attributes.
Whether it’s “How many Tradelines are 30 Days Delinquent”; or “How Many Home Equity Tradelines
have a Balance At or Above the Credit Limit”, your application will have access to these attributes
and many, many more.
When used in conjunction with Luxor’s Mapping and Merge Assistants, your application will be able
to merge multple credit files from any of the U.S. national credit repositories, Canada and Mexico;
and make complex lending decisions on any combination of data files.
Luxor components and services will enable you to:
- Create Your Own Rules - Write your own attribute rules using Luxor’s English Language Syntax.
- Endless Possibilities - Efficient, flexible design provides unprecedented customization capabilities.
- Use Luxor’s Standard Attributes - Pick and choose any or all of the over 1,600 standard attributes.
- Filter Based On Your Choices - Perform ‘What If’ scenarios including and excluding borrowers.
- Merged and Un-Merged Attributes - Retrieve attributes from merged or un-merged data.
- API or XML - Use the API; or retrieve attributes in XML with or without the credit detail data.
Contact us to find out more