Introduction

This document serves as a guide for automating the integration of Quandis Bankruptcy Search using the Quandis Data Services Platform (QDS). It describes transmission protocols utilized, the QDS Bankruptcy workflow, XML messaging and schema requirements. It will also outline general usage and common error types.

It is written for both prospective and new system integrators, consultants and other technical professionals interested in integrating with QDS.

Definitions

The following terms are referred to in this document.

QDS sends and receives data via the public internet using HTTPS (2048 bit) protocol as the standard protocol. VPN connectivity is supported under special circumstances. QDS supports the following protocols:

• SOAP (using HTTPS)
• HTTP POST (RESTful)

Preferred Transmission Patters

QDS supports an event driven transmission model whereas the preference is for the originating system to push or invoke the target end point whenever there is a need to transmit data. This is opposite from the source system polling the target system endpoint to check if data is available at any given time. As a result, we require our partners to expose an end point such as a SOAP web service or HTTPS receiver.  The end point is generally public accessible with security controlled by IP restriction and BASIC authentication.

Service Connectors

QDS supports the above protocols as standard connectivity. In some scenarios, there is a requirement to connect to an existing web service or platform using a combination of protocols to satisfy non-standard connectivity requirements for a partner. QDS can also implement Service Connectors that will facilitate this.  The usage of Service Connectors is evaluated on a per implementation basis.

Security

The following table describes the various protocols and security models used by QDS:

Web Service Host Information

The following table outlines the locations of both UAT and Production URLs. Unless otherwise stated, all URL relative paths are the same for production with only the host value changed.

Endpoints

During the lifecycle of a Bankruptcy search several events occur on the client and Quandis systems. A subset of these events requires communication of data between the various systems to facilitate order processing.

The following endpoints are exposed by QBS for bankruptcy search events:

Client Specific Endpoints

The following table outlines the client endpoints utilized by QDS for Bankruptcy search events:

Pacer Login

Quandis requires a Pacer login as part of setup. The interface will utilize the login for searching. Pacer allows an additional Client Code value to be set during login. A custom value can be provided as part of the Quandis setup to allow automated searching to be distinguished from manual searching for reconciliation purposes.

Product Types

The following table outlines the Product Types which can be specified in a search operation:

Search Options

Search options are individual properties used to specify the characteristics of a given search operation. Search options allow multiple properties to be set within the operation. The following table outlines the various search options available:

Search Option Response Data

The Search Options control which fields are returned in the operation response. The following table outlines the fields returned based on Search Option:

The regional search iterates through each PCL search result and submits a request to the regional site to obtain case summary status. Since the PCL site and regional sites are operated independently and accessed by different URLs, there is chance a regional site can be offline during the lifecycle of the search. The bankruptcy search can accommodate this condition and will cascade logic to return a basic search result when a given regional site is inaccessible. The purpose of this logic is to allow the bankruptcy result to be obtained when searching is time sensitive.

Search Criteria

Quandis Bankruptcy Search can accommodate the following search criteria: Full SSN, SSN4 + Party, Non-SSN + Contact.  The input determines what criteria are submitted to the bankruptcy search.

Docket Search
The Quandis Bankruptcy Search includes functionality to search docket information from within Pacer. There are two ways to search for docket information:

• Include Search Option ‘Dockets’ in Bankruptcy Search request
• Invoke stand-alone operation with Product Type ‘Docket Search’

Dockets as Part of Bankruptcy Search

This is the easiest way to search docket information. As a Search Option from a Bankruptcy Search, ‘Dockets’ can be specified. When a bankruptcy is located, the docket information will be accessed and returned in the search response. By default dockets are searched for any bankruptcy located. This can be limited by setting the Search Option ‘DocketsOpenCaseOnly’ that will only search dockets when a file does not contain a closed date. This is an effective way to reduce Pacer costs.

Dockets as Stand-Alone Search

Dockets can be searched as a stand-alone operation. This allows for dockets to be searched for a given case as an individual operation.  Invoking the Docket Search as a stand-alone operation allows for additional granularity in search options. The following search options can be specified when searching dockets:

The docket search is a two-step model such that the input for a docket search contains a CaseUrl which is contained Quandis Bankruptcy Search response Xml.

Search Thresholds

Search thresholds are implemented within the bankruptcy search to limit the amount of processing that occurs. The general purpose is to set limits on the amount of data being returned to both control costs and ensure the amount of information returned is not too broad and is not diluted in value. There are two configurable thresholds: Contact Threshold, Bankruptcy Threshold. The following table provides additional detail on each threshold:

Threshold values can be passed or omitted in the Search Options section of the request. If they are not supplied in the request they are defaulted. Quandis can set the default value per organization globally so they don’t have to be passed in every request.

As the bankruptcy responses vary, there are two indicators in the response Xml which indicate if a threshold has been reached:

An example of Contact Threshold enforcement is the following: Assume a bankruptcy search is submitted for John Doe, 123 Maple, Anywhere CA without SSN. The search will access the data provider and lookup SSN. QDS will filter the search results to each unique contact with combined unique SSN, Last Name and First Name. The data provider can potentially return more than 5 subjects to search Pacer.  If this number exceeds the threshold, the subjects will not be searched in Pacer and the response will contain a message indicating the threshold has been exceeded along with the contact information. The expected action item for the client is to review the contacts returned an submit another bankruptcy search with the SSN4 returned from Quandis.

An example of the Bankruptcy Threshold enforcement is the following: Assume a bankruptcy search is submitted for John Doe, 123 Maple, Anywhere CA with SSN and Search Options ‘RegionalSearch’ and ‘Dockets’ were specified. If Pacer Case Locator returns more than 5 bankruptcies, the operation will stop at the PCL search and not download region and docket data. The bankruptcy data will be returned and for the Contact a message will be returned indicating the threshold has been exceeded.  This threshold number is cumulative of all searches and applies to contact searching as well. In this example, if a contact search returned 3 distinct contacts which returned 2 bankruptcies each, the total number of bankruptcies is 6. This would exceed the default value of 5, so no subsequent searches would be performed. The expected action item would be to order dockets and region data as a stand-alone service if desired.

Order Submission Non Pickup Model

The following diagram depicts the QDS Bankruptcy Process for a non pickup scenario. This model encapsulates order submission by client and product submission initiated by Quandis. For each arrow, there is a corresponding Xml message that is sent from party to party. The solid lines represent mandatory messages.

Order Submission Pickup Model

The following diagram depicts the QDS Bankruptcy Process for a pickup scenario. The order submission mirrors the non-pickup model. Product delivery is addressed by the pickup model.

The following table describes the various XML message types used for Bankruptcy search and what stage in the workflow they are utilized:

Key Workflow Steps

The Bankruptcy search process contains key workflow steps or events. The following provides additional detail on these steps.

Order Submission

Order submission originates from the client system. Orders are submitted by using any of the supported protocols. QDS will evaluate the format of the message using schema validation and instantly return a success or failure in the form of a QDS acknowledgment. In the diagram above, this is represented as a separate message but is part of order submission.

PickupList (Only used in Pickup Model)

This is initiated by clients on a scheduled basis in scenarios when order type is designated for pickup. The client will invoke a web service on QDS to obtain a list of completed orders. QDS will return an Xml dataset of completed orders that is used as input for a subsequent web service call to pick up the individual order data.

Product Data

When the order has been processed on QDS, product data will remain ready for pickup or be submitted to the client endpoint.

Client Submission

Under the client submission model, QDS will deliver the product data to the client’s configured endpoint.

Order Pickup

With the pickup model, product data is returned when the client invokes the Pickup Order web service. By invoking the pickup web service, the order is automatically marked as complete. This will remove the order from the PickupList dataset. Order pickup is permitted more than once.

Quandis Bankruptcy search provides bankruptcy information using an individual’s United States Social Security Number (USSSN) or SSN4 along with Party name.

Searches can also be conducted on individuals for whom a valid USSSN is not available, provided the party information (first name, last name, address, city, state, and postal code) are provided as criteria. A typical business scenario would be a co-signer on a loan or title document. Quandis advanced search can locate USSSN based on the above criteria before submitting to the Pacer website. The process will perform a search through our internal service providers to locate the missing USSSN. The provider also provides all known aliases and addresses for reconciliation purposes.

For example:
A search for Jane Progin at 123 Main Street, Springfield, CA, 95370 (USSSN unavailable) could return:

• Progin                123 Main Street,    Springfield,    CA, 95370, USSSN = 222-22-2221
• Jane A. Palovitz 123 Main Street,    Springfield,    CA, 95370, USSSN = 222-22-2222
• Jane Progin           456 Elm Ave,        Beverly Hills, CA, 90210, USSSN = 222-22-2223

Each line item above is referred to as an alias. The alias is an individual search response from the main contact. Each unique combination of unique USSSN is submitted to Pacer for bankruptcy searching. This ensures all unique combinations USSSN are searched:

• Progin, USSSN = 222-22-2221
• Palovitz, USSSN = 222-22-2221
• Progin, USSSN = 222-22-2223

Each search returns an PDF image of the search response from Pacer Case Locator (PCL).  Each PDF image contains a billing footer with date searched, search criteria and cost. The footer can be used for search result and billing reconciliation.

Searches can also be conducted on Entity names stand-alone for whom a valid EIN/USSSN is generally unavailable. A typical business scenario would be a corporation on a loan or title document. Quandis will normalize the corporation name (if necessary) and search Pacer by Entity name.

For example:
A search with corporation name submitted as ACME Company, LLC. would normalize as:

• Company: ACME Company, Suffix: LLC

Pacer is then searched by Entity: ACME Company

Corporations can be provided as standard parties in the order request distinguished by:

• Company set to {Corporation Value}
• ContactType set to Corporation
• EIN (optional) to additionally filter by EIN

Corporate search responses are governed using same Thresholds given Entity searches have the potential to return a broad search response