Federal Parent Locator Service

Federal Case Registry

Interface Guidance Document

Document Version: 12.0

April 30, 2008

DCN: C8-02.01.10.02

Table of Contents

**10.** **Additional FCR Functions [10-1](#additional-fcr-functions)**

10.1 Multistate Financial Institution Data Match
[10-1](#multistate-financial-institution-data-match)

10.1.1 Interface with the Multistate Financial Institution
[10-2](#interface-with-the-multistate-financial-institution)

10.1.2 MSFI Response Processing [10-3](#msfi-response-processing)

10.1.3 Returning MSFIDM Responses to the States
[10-4](#returning-msfidm-responses-to-the-states)

10.1.4 Address Editing of MSFIDM Responses
[10-4](#address-editing-of-msfidm-responses)

10.1.4.1 MSFI Address Editing [10-4](#msfi-address-editing)

10.1.4.2 MSFI Matched Account Payee Address Editing
[10-4](#msfi-matched-account-payee-address-editing)

10.2 FCR SSA Death Master File Processing
[10-7](#fcr-ssa-death-master-file-processing)

10.3 FCR Data Inconsistency File [10-9](#fcr-data-inconsistency-file)

10.4 SSA's State Verification and Exchange System (SVES)
[10-10](#ssas-state-verification-and-exchange-system-sves)

10.5 SSA's Title II Pending Claim-to-FCR
[10-11](#ssas-title-ii-pending-claim-to-fcr)

10.6 DMDC Proactive Match System [10-12](#dmdc-proactive-match-system)

10.7 Insurance Matching System [10-12](#insurance-matching-system)

# Additional FCR Functions

This part describes the major new functions that have been added to the
FCR since its implementation in October of 1998.

## Multistate Financial Institution Data Match

For the purpose of securing information leading to the enforcement of
child support orders, section 466(a)(17) of the Social Security Act, as
added by section 372 of Public Law 104-193 (PRWORA), mandates States to
establish procedures under which the State Child Support Enforcement
Agency (CSEA) will enter into agreements with financial institutions
that do business in the State. The State CSEA must develop and operate,
in coordination with financial institutions doing business in that
State, a data match system. A financial institution is defined as "a
depository institution, as defined in Section 3(c) of the Federal
Deposit Insurance Act (12 U.S.C. 1813(c)); \... an
institution-affiliated party, as defined in Section 3(u) of such Act (12
U.S.C. 1813(u)); \... any Federal credit union or State credit union, as
defined in Section 101 of the Federal Credit Union Act (12 U.S.C. 1752),
including an institution-affiliated party of such credit union, as
defined in Section 206(r) of such Act (12 U.S.C. 1786(r)); \... and any
benefit association, insurance company, safe deposit company,
money-market mutual fund, or similar entity authorized to do business in
the State."

The data match process requires each financial institution to provide to
the State CSEA, on a quarterly basis, the name, address, social security
number or other taxpayer identification number and other identifying
information for each non-custodial parent, who maintains an account at
the financial institution and owes past-due support as identified by the
State CSEA. The State CSEA may provide the names and social security
numbers, or other taxpayer identification numbers, to the financial
institution or the State CSEA may accept a file of all accounts held by
the financial institution for match by the State. These procedures must
utilize automated data exchanges to the maximum extent feasible. The
financial institutions are required to encumber or surrender the assets
of the delinquent obligor held by the institution in response to a
notice of lien or levy.

Public Law 105-200 added provisions to Title IV-D of the Social Security
Act that expanded the authority of the Federal Parent Locator Service
(FPLS) to assist States in conducting data matches with Multistate
Financial Institutions (MSFI). The goals of the Multistate Financial
Institution Data Match (MSFIDM) are to:

-   reduce the burden and associated costs imposed on MSFIs and States
    to perform matching,

-   maintain the integrity and security of the financial and child
    support data, and

-   provide for the quick disbursement of matched data to the
    appropriate States.

In order to implement the provisions of the law, OCSE issued a Tax
Offset Certification Addendum to the IV-D Directors of each State. The
Addendum, when signed by a representative of the State, permits OCSE to
act on behalf of the State in the exchange of data with the MSFI, using
the case information from the Federal Offset File.

Beginning in March 1999, MSFIs received an Election Form Package. The
package defined the methods of data transmission available between the
MSFI and OCSE for participation in the MSFIDM. It includes an Election
Form that the MSFI must return to indicate its decision to participate
\[or not\] in the MSFIDM. The MSFIs electing to participate in the match
must also indicate on the Election Form the data transmission method
selected, their reporting periods, and if appropriate, their designated
data transmission service providers. The election form allows the MSFI
to designate the week within the calendar quarter it chooses to receive
the MSFIDM Quarterly File. Allowing the MSFI to elect different
reporting periods controls the flow of returned data to the States.

MSFIs electing not to participate in the OCSE process in favor of
participating with the individual States must identify the States in
which they are currently operating. OCSE will notify the States
immediately if an MSFI, operating within their State, elects not to
participate in the MSFIDM.

### Interface with the Multistate Financial Institution

States and Territories send OCSE information for the Federal Offset
File. The information is used to intercept the Federal tax refunds and
other Federal payments to delinquent obligors, to initiate U.S. Passport
denial and/or, beginning in July 1999, to match account data with MSFIs.
The Federal Offset System allows the State to designate individuals on
the file to be excluded from one or more of these uses. The Federal
Offset File is the State's interface to the MSFIDM process.

On a weekly basis the MSFIDM process accesses the Federal Offset File.
The process selects eligible records, those without an Offset Exclusion
Indicator Type of 'FIN' (Exclude for Financial Institution Data Match).
The MSFIDM process attempts to verify the SSN and Name combination from
the Federal Offset File using SSA's Enumeration Verification System. If
the SSN and Name combination for the selected records verifies, an
inquiry record is sent to the MSFI. If the SSN and Name combination do
not verify, no inquiry record is sent to the MSFI. If multiple records
are on the Federal Offset File for the same verified SSN, only one
Inquiry Record is sent to the MSFI.

The MSFIDM process sends the inquiries to the MSFI in the format defined
in the Financial Data Match Specification Handbook originally approved
by the Office of Budget and Management on March 5, 1999 using Method Two
-- Matched Accounts Method. Each participating MSFI or its designated
data transmission service provider receives an Inquiry File quarterly
based on its selected reporting week. The Inquiry File sent represents
the most current Federal Offset File information. The MSFI conducts an
internal match against its open accounts and transmits a file to OCSE to
report information on all accounts that are maintained by individuals on
the Inquiry File. Section 466(a)(17)(D)(ii) of the Social Security Act
defines an 'account' as "a demand deposit account, checking or
negotiable withdrawal order account, savings account, time deposit
account, or money-market mutual fund account".

The MSFI has up to forty-five business days to match the Inquiry File
and return information to the FPLS on the accounts matching the Inquiry
File. The MSFI must return the response in the format required by the
Data Match Specifications Handbook for the Method Two Matched Accounts
Method. The MSFI provides key information about the matched accounts and
the address for lien/levy notices.

The MSFIDM Help Desk will track the Inquiry Files sent to and the
Response Files received from the MSFI to ensure compliance with the
forty-five day turn around time. Follow-up is initiated if the MSFI
fails to respond within the specified time period.

OCSE will not reimburse MSFIs for the cost of processing the MSFIDM
inquiries. If a State's law allows, the State CSEA may pay reasonable
fees to financial institutions for conducting the data match. These fees
must not exceed the actual costs incurred by the financial institution.
If a MSFI chooses to recover the cost of processing the MSFIDM
inquiries, it must bill the individual States. Following the processing
of the MSFI Quarterly Response File, the MSFIDM process provides the
MSFI with a statistical report of the number of matches made per State
and the billing address of the States where fees are allowed. The MSFIDM
process provides the States with quarterly reports on the number of
matches made by MSFI.

### MSFI Response Processing

The MSFIDM response process is executed daily, Monday through Friday. It
edits the responses received from the MSFI. Response Files failing
critical edits are rejected and the MSFI is requested to submit a
corrected file. The accepted MSFI Response Records are matched to the
current Federal Offset File to determine the States interested in the
account information returned by the MSFI. If a case has been deleted or
the Offset Exclusion Indicator Type of 'FIN' has been added since the
Inquiry File was sent to the MSFI, the MSFI Response Record will not be
sent to the State. The FCR is accessed for each Response Record returned
to check for the presence of a Family Violence Indicator. If the Family
Violence Indicator is associated with the SSN, the MSFI Response Record
will not be sent to the State(s). Once the Family Violence Indicator
check is complete, the process matches the SSN on the MSFI matched
account to the eligible records (undeleted records with a verified SSN
and Name combination with a verified SSN and Name combination and
without a Financial Institution data match exclusion indicator) on the
Federal Offset File. An FCR MSFIDM Response Record is created for each
eligible SSN matched on the Federal Offset File. For example if the
State has two eligible records on the Federal Offset File for the same
SSN (a TANF and a non-TANF case) only one Match Response Record is sent.
If the MSFI has multiple accounts for the same SSN, Response Records are
returned for each account matched to an eligible SSN on the Federal
Offset File. The MSFIDM process combines the financial institution data
and the account information into one FCR MSFIDM Response Record for each
account matched. Payee addresses in the MSFIDM Responses are edited and,
if possible, corrected. An informative set of address status codes is
inserted into the returned records.

The MSFI Address Scrub Indicator always returns a code of 'GA' in the
first indicator field (MSFI Address Scrub Indicator 1) because these
addresses were validated before they were accepted for delivery to the
States.

Appendix H, "FCR Output Transaction Layouts", includes a description of
the FCR MSFIDM Response Record. Appendix E, "Data Dictionary", provides
additional details about the data elements included on the record.

### Returning MSFIDM Responses to the States

The FCR MSFIDM Response Records created from the MSFI responses are
sorted by State. The FCR MSFIDM Response Records are sent to the State
within two working days of the acceptance of the MSFI Response File. The
record is returned to the State in the FCR Locate Response Batch.
Appendix H, "FCR Output Transaction Layouts", includes a description of
the FCR Locate Response Batch. The FCR Locate Response Batch is included
in the file transmitted daily to the States via CONNECT:Direct.

MSFI responses are only generated for records that have verified
SSN/Name combination and that do not have Family Violence restrictions.
Section 5.3.1, "SSN Verification in the FCR", provides additional
information about the SSN verification process outcomes.

### Address Editing of MSFIDM Responses

In an effort to increase the reliability of the FCR MSFIDM response
data, OCSE has implemented MSFI address and MSFI Matched Account Payee
Address editing. The following sections describe the different way these
addresses are treated.

#### MSFI Address Editing

New MSFI addresses are edited by the Pitney-Bowes' FINALIST address
editing software, and if required, verified by a telephone call to the
institution. This process ensures that MSFI addresses are always correct
and, therefore, the general-status address scrub code in the MSFIDM
Response Records shows the MSFI addresses to be good.

#### MSFI Matched Account Payee Address Editing

United States addresses are edited, and if possible, corrected by the
Pitney-Bowes' FINALIST address editing software. Response Records
provide the States with address scrub codes that summarize the
deliverability status of the address, if and how the address was changed
and, if applicable, the corrected address. This enhancement improves the
quality of many of the United States addresses returned to the States,
but it does not eliminate all incomplete or unusable addresses. Address
information is sent to the States regardless of the results of the
address editing process.

The FCR edits MSFI Matched Account Payee Addresses for completeness as
follows:

The MSFI Matched Account Payee Address is passed to FINALIST, which
compares it to its address database. These USPS-provided database files
allow FINALIST to determine the house number range on the street, the
unit number range in a multi-dwelling building, the existence of the
street name in that city, the existence of the city name in that State,
and the matching Zip Code. It can correct certain types of spelling and
Zip Code errors. It can assign a Zip Code, if missing, by using its
city/state/Zip database. It cannot correct a bad or missing house
number, unit number, or street name, and is likely to fail in an attempt
to correct a badly misspelled street name or city name.

Addresses that receive any of the following FINALIST response types are
considered uncorrectable thus leaving the address unchanged in the
Response Record.

-   City name could not be matched to the State,

-   Street name could not be found in the city, or

-   House number is not in range for the street.

Addresses that receive the following FINALIST responses are considered
complete:

-   Good original address,

-   Zip Code is changed or assigned,

-   City name is corrected, or

-   Street name is corrected.

In the following situations the address that is provided by MSFI remains
unchanged and is in its source format:

-   Foreign address,

-   No address exists, or

-   Uncorrectable bad U.S. address.

The address scrubbing codes are inserted into the MSFIDM Response
Records as a set of three two-letter codes.

The first address scrub code represents the general status of the
address. It is always present in the Response Record, regardless of the
quality of the input address. This field contains one of the following
codes, to indicate the results of the address editing.

  ---- ---- --------------------------------------------------------------
  BA   --   Bad address: The address that was provided by the source
            remained unchanged because FINALIST was unable to correct the
            address.

  CH   --   Changed address: The address was corrected and is now
            considered by FINALIST to be a deliverable address.

  EA   --   Empty address: In the address that was provided by the
            Financial Institution, all of the address fields are spaces,
            therefore all of the address fields in the Response Record are
            spaces.

  FA   --   Foreign country address: The address was not edited and was
            left unchanged in its provided format because of the combined
            condition that FINALIST determined that it is not a good U.S.
            address and that the value in the foreign country code is
            other than spaces or 'US'. FINALIST determined it to be a
            foreign country address.

  GA   --   Good address: FINALIST has determined it to be a deliverable
            address.
  ---- ---- --------------------------------------------------------------

The second and third address scrub codes further define the results of
the address editing. The meaning of the second and third address scrub
codes depends on the first address scrub code.

The scrub codes have intelligence in the first character. A 'B' in the
first character indicates that something in the address is bad: out of
range or missing. An 'M' in the first character indicates that there is
a Mismatch between two address elements. A 'C' in the first character
indicates that a Correction was made to the specified address element.
An 'N' in the first character indicates that the address element is
Non-determined. This pattern becomes complex when the specific
combination of a second and a third code are compared to the first code.
That is because, in the process of analyzing and trying to correct the
address elements, FINALIST sets their scrub codes first. FINALIST then
tries to correct the total address and determines the general status of
the address. It is therefore necessary to check the actual meaning of a
code in the context of the general status code before drawing inferences
from the first letter alone.

The address scrubbing program may generate more than two detailed scrub
codes however the FCR returns only up to two of the detailed scrub
codes. The FCR returns the first two codes it encountered. To best
utilize the two available positions for the detailed scrub codes, giving
priority to codes that explain the reason for the failure of the address
scrubbing, 'CA', 'CC', and 'CZ' will not follow a 'BA' in the first
position.

No address scrubbing is performed on empty, foreign, and good addresses,
therefore if 'EA', 'FA', or 'GA' is in the first scrub code position, no
second or third scrub code will follow.

If the first address scrub code is 'BA' or 'CH', the possible second and
third address scrub codes are one or two of the following codes.

  ----- ---- --------------------------------------------------------------
  BR    --   Bad range. Address scrubbing failed because the house number
             is out of range for that street.

  BU    --   Bad unit number. Following a 'BA': The unit number in a
             multi-dwelling unit has a non-standard format, is out of range
             or is missing. In PO Box addresses the box number does not
             match the Zip+4 code. Following a 'CH': The address element
             was deemed un-necessary, was standardized, or was corrected in
             the Response Record.

  BX    --   Missing State code or missing State code and Zip Code.
             Following a 'BA': Assigning Zip Code was attempted but the
             address that was provided by the Locate source failed
             scrubbing and remained unchanged in the Response Record.
             Following a 'CH': The State or the Zip Code was missing but
             was assigned in the Response Record.

  CA    --   Correction of address. A misspelled or non-standard street
             name was successfully corrected in the Response Record.

  CC    --   Correction of city name. A misspelled or non-standard city
             name was successfully corrected in the Response Record.

  CZ    --   Correction of Zip Code. The Zip Code was successfully
             corrected or assigned in the Response Record.

  MA    --   Mismatched address. The street name is not found in the city.
             Following a 'BA': The address that was provided by the Locate
             source failed scrubbing and remained unchanged in the Response
             Record. Following a 'CH': The address is deliverable because
             some addresses do not require a street name.

  MX    --   Mismatched State and Zip Code. Attempt was made to correct or
             assign Zip Code. Following a 'BA': The address that was
             provided by the Locate source failed scrubbing and remained
             unchanged in the Response Record. Following a 'CH': The Zip
             Code was successfully corrected or assigned in the Response
             Record.

  NC    --   Non-determined city name. The city name cannot be determined
             or is not in standard format. Following a 'BA': The address
             that was provided by the Locate source failed scrubbing and
             remained unchanged in the Response Record. Following a 'CH':
             The city name was successfully standardized in the Response
             Record.

  NZ    --   Non-determined Zip Code. The Zip Code could not be determined.
             The address that was provided by the Locate source failed
             scrubbing and remained unchanged in the Response Record.
  ----- ---- --------------------------------------------------------------

## FCR SSA Death Master File Processing

OCSE has obtained the SSA Death Master File for use in FCR processing.
The SSA Death Master File provides the SSN, Name, Date of Death, Zip
Code of Last Residence, and the Zip Code of Lump Sum Payment for persons
reported to SSA as deceased. The file includes information only for
verified SSN and Name combinations. OCSE receives updates to the SSA
Death Master File on a monthly basis. The updates include newly reported
dates of death, changes to previously reported dates of death, and
deletions of erroneously reported dates of death.

The FCR Death Master File was built from the information provided on the
SSA Death Master File and is updated with the information contained on
the SSA Death Master Monthly Update Files.

The FCR matches verified FCR Primary SSNs against the FCR Death Master
File and notifies the States that registered the person about the
available death information. The FCR also effects date of death
corrections for verified FCR Primary SSNs as contained in the monthly
SSA Death Master File updates and notifies the respective States. This
matching process is performed for all participant types with a verified
FCR Primary SSN in both IV-D cases and Non IV-D cases, regardless of the
presence of an FV Indicator.

If the SSA Death Master File reports an SSN for an individual who has
valid multiple SSNs and the reported SSN is other than the FCR Primary
SSN, the record will not match. Therefore, the State is not notified of
the record in that case.

During the initialization process, the verified FCR Primary SSNs for all
participant types were matched against the FCR Death Master File. If a
match was made, the FCR Person Record was updated with the Date of
Death. This process is repeated for each of the SSA Death Master Monthly
Update Files.

The SSA Death Master and Monthly Update Files can include '00' as a
valid value in the day portion of the Date of Death Field. When this
occurs, the day portion of the Date of Death Field on the FCR Person
Record is defaulted to '01'.

It was also determined that there are a few SSA Death Master File
Records that include Dates of Birth that are the same as the Dates of
Death. After discussion with the States, it was decided that the FCR
should return the Date of Death information as reported on the SSA Death
Master File.

Upon implementation of the FCR Death Master File, all of the Person
Records on the FCR with verified FCR Primary SSNs were matched to the
FCR Death Master File. This matching process was performed for all
participant types in both IV-D and Non IV-D cases, regardless of the
presence of an FV Indicator. If a match was made, an FCR Query/Proactive
Match Response Record (Record Identifier 'FT') was generated that
provided the new death information.

This matching process is also performed upon the receipt of an SSA Death
Master Monthly Update File. If a match is made the FCR Query/Proactive
Match Response Record is generated. In order to identify the reason for
the Proactive Match, an additional value of 'D' (SSA Date of Death File
Update) was added for the Action Type Code. The SSA Date of Death
Indicator in position 755 indicates if the death information is flagged
to be added, changed or deleted from the State system. The matching
process only includes information for the matched person. Associated
person information is not provided during the matching process for the
SSA Death Master File. Associated person information is returned for
FCR-to-FCR Proactive Matching processing. Refer to Section 4.2.4.1,
"FCR-to-FCR Internal Search" for more information on FCR-to-FCR
Proactive Matching. Appendix H, "FCR Output Transaction Layouts",
includes a description of this record. The record was also modified to
include, in an area previously defined as Filler; the following
death-related information:

-   SSA Date of Death Indicator

-   SSA Zip Code of Last Residence

-   SSA City of Last Residence

-   SSA State of Last Residence

-   SSA Zip Code of Lump Sum Payment

-   SSA City of Lump Sum Payment

-   SSA State of Lump Sum Payment

On a daily basis, the FCR matches accepted FCR Input Person/Locate
Request Records (Record Identifier 'FP') that contain a verified Primary
SSN against the FCR Death Master File. This matching process is
performed for all participant types, regardless of the presence of an FV
indicator, when one of the following Action Type Codes is present:

A -- Add the person to the FCR,

C -- Change information for a person on the FCR, or

L -- Locate Request.

If a match is made, the death information is returned on the FCR
Person/Locate Request Acknowledgement/Error Record (Record Identifier
'FS'). The Acknowledgement is sent whenever the Date of Death is
present, even if the State elected to suppress the Acknowledgements when
no error or warning codes are present. The Date of Death Field will
contain the default of '01' when the SSA Death Master File contained
'00' in the day portion of the Date of Death Field. Refer to Appendix H,
"FCR Output Transaction Layouts", for a description of this record. The
record includes the following death related information:

-   SSA Zip Code of Last Residence

-   SSA Zip Code of Lump Sum Payment

-   SSA City of Last Residence

-   SSA State of Last Residence

-   SSA City of Lump Sum Payment

-   SSA State of Lump Sum Payment

The FCR sends the Zip Code of Last Residence and the Zip Code of Lump
Sum Payment to FINALIST for verification. If FINALIST verifies these Zip
Codes, the FCR retrieves the City and State that are associated with
these Zip Codes from the FINALIST database and returns them to the State
in the Response Record. If FINALIST does not verify the Zip Codes, the
Zip Codes are not returned to the States.

## FCR Data Inconsistency File

Upon request, the FCR produces a quarterly FCR Data Inconsistency File
that contains detailed information about identified data inconsistencies
between Participant Type, Order Indicator, Date of Birth and Sex Code.
The file contains detailed information for active Participant Types
'CH', 'CP', 'NP' and 'PF' on IV-D cases that have a verified SSN.
Participants with an FV Indicator are not included on the file.

This process was developed to allow the requesting State an opportunity
to make corrections, thereby improving the quality of the data on the
FCR. States should be aware that inconsistencies that were reported in a
prior quarter will continue to be reported on each FCR Data
Inconsistency File until they are corrected by the State.

If no inconsistencies are found, the requesting State will not receive
FCR Data Inconsistency File Records. The FCR Reconciliation/Data
Inconsistency File Header Record will be returned followed by the FCR
Reconciliation/Data Inconsistency File Trailer Record. The Trailer
Record will contain zeros in the Person Records Returned Field and in
the fields containing the counts of the number of data inconsistency
warning codes. The Response Record Count Field will contain a count of
'00000000002'. The Header and Trailer Record are included in this count.
Refer to Appendix H, Charts H-15, "FCR Reconciliation File/Data
Inconsistency File Header Record", H-18, "FCR Reconciliation File/Data
Inconsistency File Trailer Record", and H-23, "FCR Data Inconsistency
File Record", for a description of the FCR Data Inconsistency File
output record layouts.

The following data consistency edits are performed for the FCR Data
Inconsistency File. The Warning Codes that correspond to the edits are
returned on the FCR Data Inconsistency File Record:

  ------- ---------------------------------------------------------------
  IW001   The Participant Type is 'PF' (Putative father) and the Order
          Indicator is 'Y' (The State system has a record of the
          existence of a child support order that is applicable to this
          case).

  IW002   The Participant Type is 'CP' (Custodial party), 'NP'
          (Non-custodial parent) or 'PF' (Putative father), and the
          participant age is less than 11 years.

  IW003   The Sex Code is not 'F' (Female) or 'M' (Male).

  IW004   The Participant Type is 'PF' and the Sex Code is 'F'.
  ------- ---------------------------------------------------------------

These warning codes are not returned on any other FCR Response Records.

States may choose to begin receiving the quarterly FCR Data
Inconsistency File via CONNECT:Direct by sending a letter that contains
the information in Section L.2, "FCR Data Inconsistency File", of
Appendix L, "FCR Options for Data Received", to the Federal Office of
Child Support Enforcement (OCSE). The letter should be signed by an
individual authorized to make decisions affecting the statewide Child
Support System. States that do not send a letter will not receive the
FCR Data Inconsistency File. In order to facilitate prompt handling of
the request, please include in the request the following information:

## SSA's State Verification and Exchange System (SVES)

The FCR Locate process now provides States with access to SVES databases
as follows:

  ---------- ------------------------------------------------------------
  Title II   SSA Retirement, Survivors, Disability, and Health Insurance
             Benefits Information;

  Title XVI  Supplemental Security Income Benefits Information; and

  Prisoner   Information about inmates in Federal, State and local
             correctional facilities.
  ---------- ------------------------------------------------------------

The FCR will provide SVES information to State CSEAs for all Locate
Request types for adult participants. A SVES Response Record has a
Record Identifier equal to 'FK'. The four types of SVES Locate Responses
are Title II, Title XVI, Prisoner, and No SVES Match, which are
respectively identified by Locate Source Response Agency Code equal to
'E05', 'E06', 'E07' and 'E10'. SVES Response Records are presented in
Appendix H, "FCR Output Transaction Layouts".

States may request a Locate for a child participant in an IV-D case and
receive an E05 SVES Title II locate response when an 'E01' or 'ALL' is
in the Locate Source fields and the Action Type is 'A', 'C', or 'L'.
SVES Locates are allowed for children, but only using Locate Request
Type 'CS'. The error code **LE004** will be returned to the States if
the Participant Type is 'CH' and the Locate Request Type is 'AD', 'PK',
'CV' or 'LC'. If the Participant Type is not 'CH' and the locate request
type is 'AD', 'PK' or 'CV', and 'NSA' is the only source requested, the
Locate Request is rejected with an Error Code **TE027** (Invalid Locate
Source) or Warning Code **LW002** (Locate Source not Available for
Locate Request Type).

A Date of Birth is required for a SVES Locate request. If the FCR
receives a SVES request that does not contain a Date of Birth, the FCR
will attempt to find the Date of Birth (from SSA or from the FCR
system). If the Date of Birth is found, the SVES Locate will be
processed, and the Date of Birth will be returned to the submitter if
the Locate Request is 'CS'. If no Date of Birth can be identified, the
SVES Locate Request is rejected. If SVES is the only Locate source that
was requested in the Locate Request, Error Code **LE008** will be
returned. If other valid Locate sources were requested, those sources
will be searched, and Warning Code **LW003** will be returned to
indicate that the SVES request was rejected.

SVES Proactive Match

FCR will also provide States the option to automatically receive Title
II, Title XVI and Prisoner Locate Responses from the new SVES Proactive
Match interface. This new interface will create an SVES Proactive Match
Request for a person with a verified SSN, in IV-D case, with no family
violence indicated, and the participant type is 'PF' (Putative Father)
or 'NP' (Non-custodial party). States must first complete the FCR State
Verification and Exchange System (SVES) Proactive Match Election Form,
which is Figure L-5 in Appendix 'L' to participate in SVES Proactive
Matching. Once enrolled, States will have the option to also receive
SVES Proactive Matches for other IV-D case participant types 'CP' and/or
'CH'.

SVES Proactive Matching returns State positive FCR SVES Title II (E05),
Title XVI (E06) and/or Prisoner (E07) Locate Responses. It will not
return negative Locate Response, FCR SVES Not Found Response (E10).

States can continue to request a SVES Locate if the Locate Request Type
is 'CS', and the Locate Source field contains 'ALL' or 'E01' in the FCR
Input Person/Locate Request Record. The SVES Proactive Match Request
will be suppressed if a SVES Locate Request is made in conjunction with
an Add or Change Transaction.

## SSA's Title II Pending Claim-to-FCR 

The FCR will proactively return a new response record, the FCR Title II
Pending Claim Response Record (Record Identifier 'FK') with Locate
Source Response Agency Code of 'E04', when SSA identifies a Title II
Pending Claim add, and/or change, to a beneficiary SSN that matches a
person on the FCR who:

-   has a FCR verified SSN/Name combination,

-   has no family violence,

-   is in an open IV-D case,

-   if the State has chosen to receive Title II Pending Claim-to-FCR
    Proactive Matches.

The Response Record will include a default SSA District Office Mailing
Address. The main office for each State's Child Support Office will be
used to identify a default SSA District Office. OCSE is pursing a
beneficiary address as part of the Title II Pending Claim match, as a
future enhancement. At that time, the default SSA District Office
Mailing Address will be replaced with the actual SSA District Office for
the claim's beneficiary.

States that choose to participate in this proactive matching must
complete and submit an option form, which is shown as Figure L-9, "Title
II Pending Claim Response Election Form". The completed form must be
sent to the FCR Options Coordinator. Title II Pending Claim-to-FCR
Proactive Matching will take effect as soon as the form is entered into
the FCR.

## DMDC Proactive Match System

The FCR Defense Manpower Data Center (DMDC) Proactive Match Subsystem
determines if a child on an open IV-D case is eligible for enrollment or
is currently enrolled for military health benefits.

The FCR sends to States a DMDC file of children and the associated
non-custodial parents (NCPs), putative fathers (PFs), custodial parties
(CPs) and other sponsors from participating States that meet selection
criteria for matching purposes. DMDC then matches the DMDC request
against the Defense Enrollment Eligibility Reporting System (DEERS) to
determine military health benefits.

This subsystem also receives and processes the DMDC Responses and
proactively sends the results of the match to the States via the FCR
DMDC/Proactive Match Response Record. The Record Identifier for the "FCR
DMDC/Proactive Match Response Record" is 'FW'.

Refer to Appendix H, "FCR Output Transaction Layouts", for the detail
record layout of the FCR DMDC/Proactive Match Response Record.

The FCR/DMDC Proactive Match is performed on a quarterly basis and the
results sent to the States via CONNECT:Direct.

Some of the benefits of the DMDC Match are that it can:

-   Reduce the number of National Medical Support Notices sent by the
    States to DMDC.

-   Identify third party medical insurance that was previously unknown
    to the States.

-   Determine in a cost effective way whether a child is covered by
    military insurance.

-   Return medical coverage information faster than paper referrals.

Management Information (MI) statistics are captured for the FCR
DMDC/Proactive Match Responses for children's medical benefit
eligibility and medical benefit sponsorship.

The FCR/DMDC Proactive Match returns information relating to the sponsor
of the child if the sponsor is coded as 'Other' (that is, not 'CP',
'NCP' or 'PF'), and when the CH Sponsor Relationship Code (position 521)
contains either a '1' (Child), '2' (Foster Child), '3' (Pre-Adoptive
Child), or '4' (Ward).

## Insurance Matching System

The Insurance Matching System has been incorporated into the FPLS
architecture in response to federal legislation: Section 7306 of the
Deficit Reduction Act of 2005 that amended Section 452 of the Social
Security Act to authorize comparisons of information concerning
individuals who owe past-due child support with information that is
maintained by insurers (or their agents) concerning:

-   insurance claims,

-   settlements,

-   awards, and

-   payments

as outlined in the legislative language below, which clearly addresses
insurer non-liability for disclosure of insurance-related information
for child support reporting purposes.

The objective of the insurance match is to identify insurance claims
that are payable to individuals who are delinquent in their child
support obligation. The insurance match legislation grants OCSE the
authority to conduct the match with insurers and to provide the
information to the State Child Support Enforcement (CSE) agencies that
are responsible for collecting child support from the delinquent
obligors. This legislation provides a new tool to assist State CSE
agencies in their efforts to collect delinquent child support. The goals
of the centralized insurance match include:

-   offering insurers and States an efficient, standardized and
    cost-effective method for insurance claim matching,

-   increasing insurer participation in insurance claim matching,

-   providing States with insurance claim information, and

-   increasing child support collections by the intercepting of these
    insurance claim payouts

State and Insurer participation in the Insurance match is voluntary.

The Insurance Matching System serves as a centralized matching process
to associate delinquent obligor information that is maintained by OCSE
(as retrieved from the Federal Offset System), and claimant information
that is maintained by insurers or their agents.

Processing of Received Insurance Claimant Data

The system will receive claim data from claim providers via CONNECT:
Direct in either a standardized input file or in a file whose data can
be mapped to the standardized input file. Each received file is edited
and any file-level or record-level rejects are identified for Help Desk
follow-up with the source.

[Required fields include:]{.underline} Insurer Name, Insurer Address,
Claimant SSN, Claimant First Name, and Claimant Last Name.

[On each record, available claimant insurance information is
populated:]{.underline} Claim data, Claimant identifying data, Insurer
identifying data, Attorney identifying data, Third Party Administrator
identifying data, and Employer identifying data.

Some data elements are edited to benefit State processing:

-   All addresses are edited and the results retained.

-   All date fields are checked to ensure these are valid. If not, the
    date field is populated with blanks.

-   For those output data elements that have a standard set of values,
    an edit is performed to ensure that the input field is populated
    with a valid value. If not, it is populated with spaces or a valid
    value. Examples: Gender Code, Insurance Claim Payout Frequency Code,
    Insurance Claim Status Code, Obligor Match Code, Insurance Product
    Claim Type

-   Cross-field Editing:

```{=html}
<!-- -->
```
-   Ensure that if the Foreign-Country-Name field is populated, the
    Foreign-Country-Indicator field is appropriately set.

-   Ensure that the Insurance Claim Beneficiary Indicator is
    appropriately set based on the presence of a Life Insurance Claim
    value within the Insurance Product Claim Type field.

Matching of Claimant Data to Obligor Data

Matching takes place by comparing this received data against the file of
insurance match eligible obligors. The file of eligible obligors
consists of obligors/cases from the Federal Offset System who have the
following characteristics:

-   The case is not excluded from insurance matching.

-   The case is open.

-   The obligor's arrearage amount exceeds a State minimum arrearage
    amount.

-   The obligor does not have a Family Violence status on the FCR.

The matching of claimant identifying data (i.e., SSN, Name, Address, and
Date of Birth) against insurance match eligible obligors is performed
for each successfully processed record. The Insurer Provided SSN,
Claimant First Name, Claimant Last Name, Claimant Birth Date, and the
Claimant Address fields are used to determine the quality of the match
and the results are populated in the Obligor Match Code field.

These successful matches are stored in a database for each insurance
match program participating State whose case is associated with this
obligor. Received records that are not matched are not maintained.

Providing Matched Data to a State

The Insurance Matching System provides successfully matched record data
by populating it on a two-part Insurance Match response record for the
insurance match program participating States. Each "new" or "update"
record consists of all the received Claimant Insurance information along
with a few supplemental fields as populated by the system (e.g., SSN
Verification Code, Claim-Update-Indicator). The system also ensures that
a record is not provided: if it duplicates a previously provided record
to the State, or if the Claim Provider or Insurer Agency, per State
request, is not to be matched. Each record is provided to the FCR which
combines these with other Locate Response records in the FCR State
Response Batch.