US20090254381A1 - System for maintaining an escrow account for reimbursing administrators of payments - Google Patents
System for maintaining an escrow account for reimbursing administrators of payments Download PDFInfo
- Publication number
- US20090254381A1 US20090254381A1 US12/484,918 US48491809A US2009254381A1 US 20090254381 A1 US20090254381 A1 US 20090254381A1 US 48491809 A US48491809 A US 48491809A US 2009254381 A1 US2009254381 A1 US 2009254381A1
- Authority
- US
- United States
- Prior art keywords
- tpa
- tool
- escrow account
- company
- ability
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
- 238000012545 processing Methods 0.000 claims abstract description 12
- 238000004891 communication Methods 0.000 claims description 4
- 238000011084 recovery Methods 0.000 claims description 4
- 238000012544 monitoring process Methods 0.000 claims description 2
- 239000000969 carrier Substances 0.000 claims 3
- 238000000034 method Methods 0.000 abstract description 24
- 230000000694 effects Effects 0.000 abstract description 15
- 230000008569 process Effects 0.000 abstract description 13
- 238000006243 chemical reaction Methods 0.000 abstract description 2
- 238000012550 audit Methods 0.000 abstract 1
- 238000007726 management method Methods 0.000 abstract 1
- 238000011028 process validation Methods 0.000 abstract 1
- 229920006345 thermoplastic polyamide Polymers 0.000 description 94
- KKEYFWRCBNTPAC-UHFFFAOYSA-N Terephthalic acid Chemical compound OC(=O)C1=CC=C(C(O)=O)C=C1 KKEYFWRCBNTPAC-UHFFFAOYSA-N 0.000 description 34
- 238000005516 engineering process Methods 0.000 description 20
- 238000011835 investigation Methods 0.000 description 5
- 238000012552 review Methods 0.000 description 4
- 230000006870 function Effects 0.000 description 3
- 230000008901 benefit Effects 0.000 description 2
- 238000010586 diagram Methods 0.000 description 2
- 230000000737 periodic effect Effects 0.000 description 2
- 238000012546 transfer Methods 0.000 description 2
- 238000012795 verification Methods 0.000 description 2
- 230000009471 action Effects 0.000 description 1
- 230000015556 catabolic process Effects 0.000 description 1
- 230000001413 cellular effect Effects 0.000 description 1
- 238000004590 computer program Methods 0.000 description 1
- 238000013479 data entry Methods 0.000 description 1
- 230000001934 delay Effects 0.000 description 1
- 230000036541 health Effects 0.000 description 1
- 238000012423 maintenance Methods 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000004044 response Effects 0.000 description 1
- 230000003442 weekly effect Effects 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
- G06Q40/02—Banking, e.g. interest calculation or account maintenance
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q10/00—Administration; Management
- G06Q10/08—Logistics, e.g. warehousing, loading or distribution; Inventory or stock management
- G06Q10/087—Inventory or stock management, e.g. order filling, procurement or balancing against orders
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/08—Payment architectures
- G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q30/00—Commerce
- G06Q30/018—Certifying business or products
- G06Q30/0185—Product, service or business identity fraud
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
- G06Q40/08—Insurance
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q50/00—Systems or methods specially adapted for specific business sectors, e.g. utilities or tourism
- G06Q50/10—Services
- G06Q50/18—Legal services; Handling legal documents
Definitions
- the subject technology relates to managing claims payment transactions involving a third party administrator and a method for gathering, processing, disseminating, reconciling and controlling information relating to these payment transactions as utilized by a company such as a property and casualty insurance company.
- TPA third party adjusting or administration firms
- TPAs outside third party adjusting or administration firms
- the insurance companies must give large escrow or suspense deposits to the TPAs, which are used for paying losses.
- TPAs make payment requests in one month and then the loss data supporting those payments and any other transactions, such as claims payment set-ups, closings, or reserve changes, are submitted to the insurance company the following month.
- the insurance companies replenish the escrow accounts.
- large sums of capital are poorly deployed by being held in reserve in bank escrow accounts for use by the TPAs.
- the insurance companies use the paid loss information supplied by the TPA to adjust their general ledger for paid loss activity.
- the work to fund the TPAs and record the paid losses is manual and does not allow detailed verification for every payment.
- the payment information is summarized and manually scanned, at best, for accuracy.
- the insurance company may end-up with a large credit exposure in the event of a default by the TPA.
- a system without accurate tracking allows for clerical errors such as double payment and may tempt an unscrupulous TPA to improperly use or steal a portion of the escrow account. This process only becomes more complicated considering the fact that many large insurance companies use a plurality of TPAs to handle their books of business.
- the subject technology provides an efficient and accurate method for reducing escrow accounts, verifying payment accuracy of the TPAs and assisting with balancing the ledger of said payments.
- An embodiment of the subject invention enables the insurance company to reduce its loss fund escrow balances with TPAs to a fraction of what was necessary previously in the manual loss funding method.
- the TPAs are funded on a daily basis as opposed to a monthly basis or longer time frame.
- the insurance company is also able to obtain real-time loss related data (i.e., claim, policy and check payment detail), which enables the insurance company to verify the accuracy of the payment request immediately.
- the insurance company is able to create a paid loss database from which it is able to quickly and accurately input data into its general ledger in the months following the payments.
- the insurance company is able to handle large volumes of loss payment activity from multiple TPAs on a daily basis and quickly assess the accuracy of the funding requests.
- the subject technology has the ability to determine if a request includes payments previously made or if the request is invalid for any number of other reasons.
- the TPA is immediately notified of the error and is asked to resubmit the request without the errors.
- the process also enables the TPAs to always have sufficient funds on-hand with a quick turnaround of their funding requests.
- large loss requests for such things as settlements are also handled and tracked on one of the many reports available to determine if the funds issued to the TPA were being withheld by the TPA for an unreasonable period of time, or if the TPA issued a check to a claimant that was still not cashed or deposited by the claimant.
- a preferred embodiment also allows such holding company system to identify the particular company that the payment is being made from through information contained in a daily request file received from the TPAs. While a TPA may be able to convey information relating to which particular company is being charged for a loss payment, it is a difficult and time consuming process where multiple companies are involved.
- the subject technology described herein enables each company to glean that information through the policy information supplied by the TPAs along with the other payment information detail.
- the subject technology allows for reconciliation between what the TPA requested in one month and what the TPA reported to the insurance company the following month.
- the subject technology facilitates entering the paid loss data into the insurance company's general ledger system, and includes a number of reports that can be used for the reconciliation process, as well as for reporting in great detail the paid loss history of the insurance company in so far as the TPA claim activity is concerned.
- the subject technology is directed to a system for facilitating processing TPA fund requests on a periodic basis.
- the system communicates with TPAs and banks via a network.
- the system includes a memory component which stores an instruction set and data related to a plurality of policyholders and a processor for running the instruction set, the processor being in communication with the memory and the network.
- the processor is operative to maintain an escrow account at a first bank for use by a TPA, receive a plurality of TPA fund requests for amounts related to a plurality of payees from the TPA, approve the TPA fund requests based upon criteria, provide instructions to a second bank to transfer funds to the escrow account based on approval of the TPA fund requests and monitor payment and clearance of the amounts from the escrow account.
- the subject technology is directed to a method for implementing an escrow account for a TPA in a network.
- the method includes the steps of establishing an escrow account at a bank, wherein the bank is in communication with the network, receiving a funding request from a TPA, the fund request being an electronic data file including a claim number, an amount, a check number and a check date, approving the fund request based upon the claim number, the amount, the check number and the check date, providing funds to the escrow account equal to the amount and monitoring clearance of the funds from the escrow account.
- the company is a subsidiary of a holding company having a plurality of subsidiaries utilizing the same loss ledger system.
- FIG. 1 is an overview of a network environment in which a loss ledger system in accordance with the subject technology may be implemented
- FIG. 1A is a somewhat schematic version of a system used by the company during the implementation of the subject technology
- FIG. 2 is a schematic flowchart for a front-end process in accordance with the subject technology.
- FIG. 3 is a table showing summary processing of escrow accounts for three companies in accordance with the subject technology.
- the present invention overcomes many of the prior art problems associated with reconciling ledger accounts administrated by TPAs.
- the advantages, and other features of the system disclosed herein, will become more readily apparent to those having ordinary skill in the art from the following detailed description of certain preferred embodiments taken in conjunction with the drawings which set forth representative embodiments of the present invention.
- FIG. 1 there is shown a block diagram of an environment 10 with a loss ledger system embodying and implementing the methodology of the present disclosure.
- the environment 10 interconnects a company 12 with a plurality of TPAs 14 , banks 16 , managing general agencies/brokers (individually, an “MGA” or collectively, “MGAs”) 20 and the like via a network 18 .
- the company 12 is an insurance company that uses TPAs to make payments to qualified subscribers.
- the company 12 and TPAs 14 work with MGAs 20 , where the MGAs 20 serve as the retail side of the insurance industry.
- the subject technology matches funding request details submitted by TPAs 14 with data compiled by the company 12 and banks 16 .
- Each component 12 , 14 , 16 , 18 , 20 of the environment 10 includes one or more servers (not shown) which communicates with the network 18 via communication channels, whether wired or wireless, as is well known to those of ordinary skill in the pertinent art.
- the network 18 is the Internet.
- the servers host multiple Web sites and houses multiple databases necessary for the proper operation of the loss ledger system (LLS) 50 (see FIG. 1A ) in accordance with the subject invention.
- the servers are any of a number of servers known to those skilled in the art that are intended to be connected to or part of a network so as to link clients or end user computers at the entities 12 , 14 , 16 , 20 via the network 18 .
- the network 18 may include any number of network systems well known to those skilled in the art.
- distributed computer network 18 may be a combination of local area networks (LAN), wide area networks (WAN) as is well known.
- LAN local area networks
- WAN wide area networks
- the preferred method of accessing information is the World Wide Web because navigation is intuitive and does not require technical knowledge.
- the environment 10 includes a plurality of computers or clients (not shown) such as desktop computers, laptop computers, personal digital assistants, cellular telephones and the like.
- the clients allow users to interact with the servers to access information and conduct transactions within the environment 10 .
- the components 12 , 14 , 16 , 18 are shown without servers and/or client computers, but it is understood that each would have a plurality of such devices that would be interchangeable such that a plurality of users can utilize the environment 10 simultaneously.
- a simplified environment 10 is illustrated in FIG. 1 , such illustration shall not be construed as limiting the present invention to the illustrated embodiment.
- the LLS 50 is embodied in a server operated by the company 12 .
- the LLS 50 is equipped to interact with the network 18 and/or with components 14 , 16 , 20 directly as is well-known to those of ordinary skill in the pertinent art.
- the LLS 50 includes several functional modules that allow implementation of the subject technology.
- a capture tool 52 of the LLS 50 serves to send and receive, format and compile data files from a plurality of sources.
- a reconciliation tool 54 of the LLS 50 serves to analyze the databases created by the capture tool 52 .
- An administration tool 56 of the LLS 50 serves to coordinate the processing of the capture tool 52 and reconciliation tool 54 as well as generate reports for the company 12 .
- the LLS 50 also provides for security maintenance. Therefore, although each user (e.g., the employees of the company 12 , TPAs 14 , and banks 16 ) have access thereto, each group's access is controlled.
- the LLS 50 specifies which aspects of the program can be accessed/utilized, and at what level in order to maintain an appropriate, secure electronic ledger.
- FIG. 2 there is shown a schematic flowchart for a front-end process 100 in accordance with the subject technology.
- the following description is with respect to a single TPA 14 , TPA bank 16 and MGA 20 for simplicity, although it is to be appreciated that the process 100 is occurring with a plurality of each simultaneously for the same company 12 .
- a TPA 14 is engaged by the company 12 to administrate payment to policyholders.
- the MGA 20 will have written the policy and be involved in the claim approval process.
- the company 12 establishes an escrow account associated with the TPA 14 .
- the escrow account is with a bank 16 and, particularly, a TPA bank 16 associated with the TPA 14 .
- the TPA 14 issues checks from the escrow account. As a result, the TPA 14 provides the check to the qualified claimants. Upon cashing the check, the funds are removed from the TPA escrow account at the TPA bank 16 .
- the TPA 14 collects the check clearance information from the TPA bank 16 , the issued check information and like information related to the escrow account for submission to the company 12 .
- each check cashed and cleared from the escrow account plus each outstanding check is required in order to make sure that sufficient funds will be present to cover any and all obligations.
- each check is also associated with a policy number to identify the claimant.
- these TPA activity files are created daily by the TPA 14 and TPA bank 16 and sent to the company 12 via FTP across the network 18 .
- the TPA 14 and TPA bank 16 summarize the activity related to the TPA escrow account for the capture tool 52 but the company bank 16 used to fund the TPA escrow account also generates an activity report for the capture tool 52 .
- the TPA 14 also provides policy data to the company 12 and TPA 14 .
- This TPA activity data includes information such as claim updates, rejected transactions and the like.
- the TPA activity data is formatted in a standard manner for entry without conversion by the capture tool 52 .
- the capture tool 52 of the company 12 feeds the TPA activity data into a database containing similar information from all the TPAs 14 .
- the records associated with each TPA 14 also are grouped to form a transaction history for each TPA 14 .
- the reconciliation tool 54 of the LLS 50 uses the coordinating data from the TPA bank 16 , company bank 16 and MGA 20 regarding the claims administration for cross-checking the data of the TPA 14 .
- the FR is immediately flagged and rejected, and the TPA 14 is notified by the company to take corrective action and resubmit such payment request.
- the LLS 50 applies rules to each FR and, in turn, prevents incorrect data entry.
- the reconciliation tool 54 and administration tool 56 of the company 12 further process the data.
- the reconciliation tool 54 generates a daily summary of FRs for each TPA escrow account.
- the reconciliation tool 54 attempts to match each FR or detail of every TPA escrow account. FRs that are matched or pre-approved proceed to be processed for payment. Unmatched FRs are not funded, and further investigation and reconciliation occurs.
- the administration tool 56 provides a proper instruction report to the appropriate bank 16 , (e.g., the company bank 16 ).
- this bank instruction report is uploaded daily by the company bank 16 over a secure connection and/or protected by encryption technology.
- the administration tool 56 also generates reports related to the activity of the capture tool 52 and reconciliation tool 54 for review by the company 12 .
- the reports include data related to current escrow balance and daily, weekly and monthly cash flow, outstanding liabilities related to checks yet to clear, yet to be filled FRs and the like.
- the administration tool 56 also generates reports, which summarize and highlight any discrepancies such as improper payments or TPA fund requests with no corresponding entry from a-TPA.
- the company bank 16 processes the FRs of the instruction report.
- the company 12 coordinates release of the FRs through a portal to the company bank 16 .
- the processing includes the company bank 16 completing automated clearinghouse (“ACH”) transactions for each escrow account requiring funds for each TPA 14 .
- ACH automated clearinghouse
- the reconciliation tool 54 monitors the progress of the transactions to confirm funding of the escrow accounts. Upon completion of uploading the daily instruction reports to the bank and notifying the company treasury department, the reconciliation tool 54 updates the status of the transactions to “approved.” The reconciliation tool 54 further confirms that the approved transactions result in the funds being sent to the respective TPA bank 16 . As noted above, records of each of these activities are provided to the company 12 for verification checking.
- the company 12 then wire transfers to the company bank 16 funds to reimburse the day's ACH transactions to the TPA banks 16 .
- the reconciliation tool 54 updates the general ledger of the company 12 related to losses paid to TPAs 14 at step 116 .
- the general ledger is updated to reflect all current activity on a daily basis.
- the general ledger is reconciled to insure that all payments made to the TPAs 14 are proper. For example, if the check number, amount, date and claim number each match the expected data, then the transaction is considered matched. If any of these four criteria have a discrepancy, then the transaction is considered unmatched.
- the administration tool 56 By keeping track of the daily obligations paid, outstanding, and upcoming, the administration tool 56 generates reports that allow minimizing the amount of funds that must be dedicated to the TPA escrow accounts. Further, unmatched transaction and other irregularities such as improper payment, untimely payment, excessive fund requests without supporting policies/claims and the like are identified for subsequent investigation.
- the timeliness and accuracy of processing claims allows the escrow amounts to be significantly reduced.
- the detailed and accessible trail of the activity allows tracking and auditing. For example, time periods regarding delays in cashing checks, or providing checks to claimants, can be tracked in “aged” reports. As a result, outstanding liabilities and performance can be tracked to efficiently utilize resources and improve efficiency.
- a TPA 14 can submit a pre-fund request (“PFR”) for significant expected losses to make sure the escrow account is adequately funded.
- PFR pre-fund request
- the LLS 50 requires a PFR for all transactions above a user-selected threshold. In one embodiment, the user-selected threshold is $25,000 to trigger the need for a PFR.
- the TPA bank 16 Upon approval by the company 12 , the TPA bank 16 is wired the appropriate amount for addition to the TPA escrow.
- a check is issued and clearance of the check from the escrow account is tracked by the LLS 50 .
- the capture tool 52 enters the PFR into the ledger database.
- the reconciliation tool 56 identifies and treats each PFR differently in order to avoid double payment.
- the administration tool 56 of the LLS 50 generates a convergence report that compares the amount funded into escrow for a TPA 14 versus the corresponding ACH for the TPA bank 16 . Over time, these two amounts should converge, hence the name convergence report. If there is an excess in the escrow funding, it is an indication of possible loss payments being made outside the LLS 50 . If there is excess in the bank ACH, it is an indication of possible payment to a TPA 14 without claimants being paid and the like.
- the LLS 50 would also provide the details of the discrepancies, i.e., specific transaction details of the unmatched amounts for further investigation.
- the LLS 50 is also envisioned to accept data from systems internal to the company 12 such as a claims processing unit. By cross-referencing each transaction to a policy number, a history can also be generated on a claimant by claimant basis. It is also envisioned that summary reports can be generated that only indicate unmatched transactions and discrepancies for review and/or investigation.
- the LLS 50 preferably also generates reports related to each TPA 14 and respective bank 16 .
- table 400 shows exemplary data for three companies (e.g., Company A, B and C). Each column represents a different total for each company.
- the first column 402 provides a total of losses paid to claimants according to a claims database of the insurance company 12 .
- the second column 404 shows the total of money paid outside the LLS 50 .
- the third column 406 shows the total money unmatched by the LLS 50 . As noted above, further breakdown to the transactional level is possible for the totals of any column.
- the fourth column 408 shows recoveries and the fifth column 410 reflects pending transactions.
- the sixth column 412 shows a total of funds reconciled by the LLS 50 .
- the company 12 is part of a holding company system that has other subsidiary companies, each of which conducts similar business.
- the LLS 50 allows the holding company to identify the particular company 12 that the payment is being made from through information contained in a daily request file received from the TPAs 14 .
- the LLS 50 parses the company specific information through the policy information supplied by the TPAs 14 along with the other payment information detail. As a result, company by company data and reports are generated even though the starting data from the TPAs 14 includes data related to a plurality of the subsidiaries or companies 12 .
- the flow charts herein illustrate the structure or the logic of the present invention as embodied in computer program software for execution on a computer, digital processor or microprocessor.
- Those skilled in the art will appreciate that the flow charts illustrate the structures of the computer program code elements, including logic circuits on an integrated circuit, that function according to the present technology.
- the present technology is practiced in its essential embodiments by a machine component that renders the program code elements in a form that instructs a digital processing apparatus such as a computer to perform a sequence of function steps corresponding to those shown in the flow diagrams.
- any functional element may perform fewer, or different, operations than those described with respect to the illustrated embodiment.
- functional elements e.g., modules, tools, databases, interfaces, computers, servers and the like
- described as distinct for purposes of illustration may be incorporated within other functional elements in a particular implementation.
Abstract
A loss ledger system to process third party fund requests on a daily basis, track historical requests, process validation on each request, maintain suspense/escrow and loss ledgers, and provide reconciliation assistance for accounting and claims processing departments. Additionally, the loss ledger system provides management reports, interfaces, security, audit and control and data conversion to facilitate minimizing escrowed resources, fraudulent activity and clerical errors.
Description
- This application claims priority to U.S. Provisional Patent Application No. 60/693,272, filed Jun. 22, 2005, which is incorporated herein by reference in its entirety.
- 1. Field of Invention
- The subject technology relates to managing claims payment transactions involving a third party administrator and a method for gathering, processing, disseminating, reconciling and controlling information relating to these payment transactions as utilized by a company such as a property and casualty insurance company.
- 2. Background of the Related Art
- Most insurance companies pay some of their claims by utilizing outside third party adjusting or administration firms (individually, a “TPA” and collectively, “TPAs”). Typically, the insurance companies must give large escrow or suspense deposits to the TPAs, which are used for paying losses. Historically, TPAs make payment requests in one month and then the loss data supporting those payments and any other transactions, such as claims payment set-ups, closings, or reserve changes, are submitted to the insurance company the following month. In response, the insurance companies replenish the escrow accounts. As a result, large sums of capital are poorly deployed by being held in reserve in bank escrow accounts for use by the TPAs.
- The insurance companies use the paid loss information supplied by the TPA to adjust their general ledger for paid loss activity. The work to fund the TPAs and record the paid losses is manual and does not allow detailed verification for every payment. Typically, the payment information is summarized and manually scanned, at best, for accuracy. Additionally, with the large escrows that must be maintained, the insurance company may end-up with a large credit exposure in the event of a default by the TPA. Further, a system without accurate tracking allows for clerical errors such as double payment and may tempt an unscrupulous TPA to improperly use or steal a portion of the escrow account. This process only becomes more complicated considering the fact that many large insurance companies use a plurality of TPAs to handle their books of business.
- In light of the problems described with the current method of paying claims through the use of TPAs, there is a need for an improved method of funding the escrow accounts and managing the data associated with this process. The subject technology provides an efficient and accurate method for reducing escrow accounts, verifying payment accuracy of the TPAs and assisting with balancing the ledger of said payments.
- An embodiment of the subject invention enables the insurance company to reduce its loss fund escrow balances with TPAs to a fraction of what was necessary previously in the manual loss funding method. Preferably, the TPAs are funded on a daily basis as opposed to a monthly basis or longer time frame. The insurance company is also able to obtain real-time loss related data (i.e., claim, policy and check payment detail), which enables the insurance company to verify the accuracy of the payment request immediately. Also, the insurance company is able to create a paid loss database from which it is able to quickly and accurately input data into its general ledger in the months following the payments.
- In addition to the return of escrow funds, which can then be used for investment or other purposes, the insurance company is able to handle large volumes of loss payment activity from multiple TPAs on a daily basis and quickly assess the accuracy of the funding requests. The subject technology has the ability to determine if a request includes payments previously made or if the request is invalid for any number of other reasons. The TPA is immediately notified of the error and is asked to resubmit the request without the errors. The process also enables the TPAs to always have sufficient funds on-hand with a quick turnaround of their funding requests. Preferably, large loss requests for such things as settlements are also handled and tracked on one of the many reports available to determine if the funds issued to the TPA were being withheld by the TPA for an unreasonable period of time, or if the TPA issued a check to a claimant that was still not cashed or deposited by the claimant.
- Where the insurance company is part of a holding company system that has other subsidiary insurance companies, a preferred embodiment also allows such holding company system to identify the particular company that the payment is being made from through information contained in a daily request file received from the TPAs. While a TPA may be able to convey information relating to which particular company is being charged for a loss payment, it is a difficult and time consuming process where multiple companies are involved. The subject technology described herein enables each company to glean that information through the policy information supplied by the TPAs along with the other payment information detail.
- Preferably, the subject technology allows for reconciliation between what the TPA requested in one month and what the TPA reported to the insurance company the following month. By analyzing the details of each payment transaction and quickly responding to the TPAs with any necessary changes, payment errors are greatly reduced, the recording of paid losses is more accurate and the opportunity for misappropriation is reduced. In a further aspect, the subject technology facilitates entering the paid loss data into the insurance company's general ledger system, and includes a number of reports that can be used for the reconciliation process, as well as for reporting in great detail the paid loss history of the insurance company in so far as the TPA claim activity is concerned.
- In one embodiment, the subject technology is directed to a system for facilitating processing TPA fund requests on a periodic basis. The system communicates with TPAs and banks via a network. The system includes a memory component which stores an instruction set and data related to a plurality of policyholders and a processor for running the instruction set, the processor being in communication with the memory and the network. The processor is operative to maintain an escrow account at a first bank for use by a TPA, receive a plurality of TPA fund requests for amounts related to a plurality of payees from the TPA, approve the TPA fund requests based upon criteria, provide instructions to a second bank to transfer funds to the escrow account based on approval of the TPA fund requests and monitor payment and clearance of the amounts from the escrow account.
- In another aspect, the subject technology is directed to a method for implementing an escrow account for a TPA in a network. The method includes the steps of establishing an escrow account at a bank, wherein the bank is in communication with the network, receiving a funding request from a TPA, the fund request being an electronic data file including a claim number, an amount, a check number and a check date, approving the fund request based upon the claim number, the amount, the check number and the check date, providing funds to the escrow account equal to the amount and monitoring clearance of the funds from the escrow account.
- In a further aspect, the company is a subsidiary of a holding company having a plurality of subsidiaries utilizing the same loss ledger system.
- It should be appreciated that the present invention can be implemented and utilized in numerous ways, including without limitation as a process, an apparatus a system, a device, a method for applications now known and later developed and a computer readable medium. These and other unique features of the system disclosed herein will become more readily apparent from the following description and the accompanying drawings.
- In order that those having ordinary skill in the art to which the disclosed system appertains will more readily understand how to make and use the same, reference may be had to the drawings wherein:
-
FIG. 1 is an overview of a network environment in which a loss ledger system in accordance with the subject technology may be implemented; -
FIG. 1A is a somewhat schematic version of a system used by the company during the implementation of the subject technology; -
FIG. 2 is a schematic flowchart for a front-end process in accordance with the subject technology; and -
FIG. 3 is a table showing summary processing of escrow accounts for three companies in accordance with the subject technology. - The present invention overcomes many of the prior art problems associated with reconciling ledger accounts administrated by TPAs. The advantages, and other features of the system disclosed herein, will become more readily apparent to those having ordinary skill in the art from the following detailed description of certain preferred embodiments taken in conjunction with the drawings which set forth representative embodiments of the present invention.
- Referring now to
FIG. 1 , there is shown a block diagram of anenvironment 10 with a loss ledger system embodying and implementing the methodology of the present disclosure. Theenvironment 10 interconnects acompany 12 with a plurality ofTPAs 14,banks 16, managing general agencies/brokers (individually, an “MGA” or collectively, “MGAs”) 20 and the like via anetwork 18. In one embodiment, thecompany 12 is an insurance company that uses TPAs to make payments to qualified subscribers. Thecompany 12 and TPAs 14 work with MGAs 20, where the MGAs 20 serve as the retail side of the insurance industry. In brief overview, the subject technology matches funding request details submitted by TPAs 14 with data compiled by thecompany 12 andbanks 16. Although the subject technology is particularly suited to such an application, health care providers and many other industries can benefit from the technology disclosed herein. The following discussion describes the structure of such anenvironment 10, but further discussion of the application programs and databases that embody the methodology of the present invention is described elsewhere herein. - Each
component environment 10 includes one or more servers (not shown) which communicates with thenetwork 18 via communication channels, whether wired or wireless, as is well known to those of ordinary skill in the pertinent art. In one preferred embodiment, thenetwork 18 is the Internet. The servers host multiple Web sites and houses multiple databases necessary for the proper operation of the loss ledger system (LLS) 50 (seeFIG. 1A ) in accordance with the subject invention. The servers are any of a number of servers known to those skilled in the art that are intended to be connected to or part of a network so as to link clients or end user computers at theentities network 18. - The
network 18 may include any number of network systems well known to those skilled in the art. For example, distributedcomputer network 18 may be a combination of local area networks (LAN), wide area networks (WAN) as is well known. For the Internet, the preferred method of accessing information is the World Wide Web because navigation is intuitive and does not require technical knowledge. - It is envisioned that the
environment 10 includes a plurality of computers or clients (not shown) such as desktop computers, laptop computers, personal digital assistants, cellular telephones and the like. The clients allow users to interact with the servers to access information and conduct transactions within theenvironment 10. For simplicity, thecomponents environment 10 simultaneously. Although asimplified environment 10 is illustrated inFIG. 1 , such illustration shall not be construed as limiting the present invention to the illustrated embodiment. - Referring now to
FIG. 1A , there is shown a somewhat schematic version of aLLS 50 used by thecompany 12. In one embodiment, theLLS 50 is embodied in a server operated by thecompany 12. TheLLS 50 is equipped to interact with thenetwork 18 and/or withcomponents LLS 50 includes several functional modules that allow implementation of the subject technology. Acapture tool 52 of theLLS 50 serves to send and receive, format and compile data files from a plurality of sources. Areconciliation tool 54 of theLLS 50 serves to analyze the databases created by thecapture tool 52. Anadministration tool 56 of theLLS 50 serves to coordinate the processing of thecapture tool 52 andreconciliation tool 54 as well as generate reports for thecompany 12. - The
LLS 50 also provides for security maintenance. Therefore, although each user (e.g., the employees of thecompany 12,TPAs 14, and banks 16) have access thereto, each group's access is controlled. TheLLS 50 specifies which aspects of the program can be accessed/utilized, and at what level in order to maintain an appropriate, secure electronic ledger. - Referring now to
FIG. 2 , there is shown a schematic flowchart for a front-end process 100 in accordance with the subject technology. The following description is with respect to asingle TPA 14,TPA bank 16 andMGA 20 for simplicity, although it is to be appreciated that theprocess 100 is occurring with a plurality of each simultaneously for thesame company 12. Initially, aTPA 14 is engaged by thecompany 12 to administrate payment to policyholders. Typically, theMGA 20 will have written the policy and be involved in the claim approval process. Thecompany 12 establishes an escrow account associated with theTPA 14. The escrow account is with abank 16 and, particularly, aTPA bank 16 associated with theTPA 14. Atstep 102, as qualified claimants request payment on their policies, theTPA 14 issues checks from the escrow account. As a result, theTPA 14 provides the check to the qualified claimants. Upon cashing the check, the funds are removed from the TPA escrow account at theTPA bank 16. - At
step 104, theTPA 14 collects the check clearance information from theTPA bank 16, the issued check information and like information related to the escrow account for submission to thecompany 12. For example, in the insurance industry, each check cashed and cleared from the escrow account plus each outstanding check is required in order to make sure that sufficient funds will be present to cover any and all obligations. Typically, each check is also associated with a policy number to identify the claimant. Preferably, these TPA activity files are created daily by theTPA 14 andTPA bank 16 and sent to thecompany 12 via FTP across thenetwork 18. - Not only do the
TPA 14 andTPA bank 16 summarize the activity related to the TPA escrow account for thecapture tool 52 but thecompany bank 16 used to fund the TPA escrow account also generates an activity report for thecapture tool 52. As necessary, theTPA 14 also provides policy data to thecompany 12 andTPA 14. This TPA activity data includes information such as claim updates, rejected transactions and the like. Preferably, the TPA activity data is formatted in a standard manner for entry without conversion by thecapture tool 52. - At
step 106, thecapture tool 52 of thecompany 12 feeds the TPA activity data into a database containing similar information from all the TPAs 14. The records associated with eachTPA 14 also are grouped to form a transaction history for eachTPA 14. Thereconciliation tool 54 of theLLS 50 uses the coordinating data from theTPA bank 16,company bank 16 andMGA 20 regarding the claims administration for cross-checking the data of theTPA 14. As a result, if a FR includes an error, whether it be for a second payment request on the same claim or of a clerical nature, the FR is immediately flagged and rejected, and theTPA 14 is notified by the company to take corrective action and resubmit such payment request. As can be seen, theLLS 50 applies rules to each FR and, in turn, prevents incorrect data entry. - Once the TPA, MGA, TPA bank and company bank activity data are compiled by the
capture tool 52, thereconciliation tool 54 andadministration tool 56 of thecompany 12 further process the data. For example, thereconciliation tool 54 generates a daily summary of FRs for each TPA escrow account. Thereconciliation tool 54 attempts to match each FR or detail of every TPA escrow account. FRs that are matched or pre-approved proceed to be processed for payment. Unmatched FRs are not funded, and further investigation and reconciliation occurs. - At
step 108, in order to meet the matched FRs, theadministration tool 56 provides a proper instruction report to theappropriate bank 16, (e.g., the company bank 16). Preferably, this bank instruction report is uploaded daily by thecompany bank 16 over a secure connection and/or protected by encryption technology. - The
administration tool 56 also generates reports related to the activity of thecapture tool 52 andreconciliation tool 54 for review by thecompany 12. For example, the reports include data related to current escrow balance and daily, weekly and monthly cash flow, outstanding liabilities related to checks yet to clear, yet to be filled FRs and the like. Further, theadministration tool 56 also generates reports, which summarize and highlight any discrepancies such as improper payments or TPA fund requests with no corresponding entry from a-TPA. - At
step 110, thecompany bank 16 processes the FRs of the instruction report. Preferably, thecompany 12 coordinates release of the FRs through a portal to thecompany bank 16. The processing includes thecompany bank 16 completing automated clearinghouse (“ACH”) transactions for each escrow account requiring funds for eachTPA 14. - At
step 112, thereconciliation tool 54 monitors the progress of the transactions to confirm funding of the escrow accounts. Upon completion of uploading the daily instruction reports to the bank and notifying the company treasury department, thereconciliation tool 54 updates the status of the transactions to “approved.” Thereconciliation tool 54 further confirms that the approved transactions result in the funds being sent to therespective TPA bank 16. As noted above, records of each of these activities are provided to thecompany 12 for verification checking. - At
step 114, thecompany 12 then wire transfers to thecompany bank 16 funds to reimburse the day's ACH transactions to theTPA banks 16. Upon reimbursement, thereconciliation tool 54 updates the general ledger of thecompany 12 related to losses paid to TPAs 14 atstep 116. Preferably, the general ledger is updated to reflect all current activity on a daily basis. The general ledger is reconciled to insure that all payments made to theTPAs 14 are proper. For example, if the check number, amount, date and claim number each match the expected data, then the transaction is considered matched. If any of these four criteria have a discrepancy, then the transaction is considered unmatched. - By keeping track of the daily obligations paid, outstanding, and upcoming, the
administration tool 56 generates reports that allow minimizing the amount of funds that must be dedicated to the TPA escrow accounts. Further, unmatched transaction and other irregularities such as improper payment, untimely payment, excessive fund requests without supporting policies/claims and the like are identified for subsequent investigation. - As can be seen, the timeliness and accuracy of processing claims allows the escrow amounts to be significantly reduced. The detailed and accessible trail of the activity allows tracking and auditing. For example, time periods regarding delays in cashing checks, or providing checks to claimants, can be tracked in “aged” reports. As a result, outstanding liabilities and performance can be tracked to efficiently utilize resources and improve efficiency.
- In a preferred embodiment, a
TPA 14 can submit a pre-fund request (“PFR”) for significant expected losses to make sure the escrow account is adequately funded. As a general rule, theLLS 50 requires a PFR for all transactions above a user-selected threshold. In one embodiment, the user-selected threshold is $25,000 to trigger the need for a PFR. Upon approval by thecompany 12, theTPA bank 16 is wired the appropriate amount for addition to the TPA escrow. Upon payment of the loss, a check is issued and clearance of the check from the escrow account is tracked by theLLS 50. Thecapture tool 52 enters the PFR into the ledger database. Thereconciliation tool 56 identifies and treats each PFR differently in order to avoid double payment. - In one embodiment, the
administration tool 56 of theLLS 50 generates a convergence report that compares the amount funded into escrow for aTPA 14 versus the corresponding ACH for theTPA bank 16. Over time, these two amounts should converge, hence the name convergence report. If there is an excess in the escrow funding, it is an indication of possible loss payments being made outside theLLS 50. If there is excess in the bank ACH, it is an indication of possible payment to aTPA 14 without claimants being paid and the like. TheLLS 50 would also provide the details of the discrepancies, i.e., specific transaction details of the unmatched amounts for further investigation. - As would be apparent to those of ordinary skill in the pertinent art upon review of the subject disclosure, such information as shown in the convergence report could then be used to evaluate the circumstances. If a high-level authorized user reviews the data, such a user can, on a periodic basis, qualify the discrepancies as not needing further investigation until the next report. The
LLS 50 is also envisioned to accept data from systems internal to thecompany 12 such as a claims processing unit. By cross-referencing each transaction to a policy number, a history can also be generated on a claimant by claimant basis. It is also envisioned that summary reports can be generated that only indicate unmatched transactions and discrepancies for review and/or investigation. TheLLS 50 preferably also generates reports related to eachTPA 14 andrespective bank 16. - Referring now to
FIG. 3 , table 400 shows exemplary data for three companies (e.g., Company A, B and C). Each column represents a different total for each company. For example, thefirst column 402 provides a total of losses paid to claimants according to a claims database of theinsurance company 12. Thesecond column 404 shows the total of money paid outside theLLS 50. Thethird column 406 shows the total money unmatched by theLLS 50. As noted above, further breakdown to the transactional level is possible for the totals of any column. Thefourth column 408 shows recoveries and thefifth column 410 reflects pending transactions. Thesixth column 412 shows a total of funds reconciled by theLLS 50. - In another embodiment, the
company 12 is part of a holding company system that has other subsidiary companies, each of which conducts similar business. TheLLS 50 allows the holding company to identify theparticular company 12 that the payment is being made from through information contained in a daily request file received from theTPAs 14. TheLLS 50 parses the company specific information through the policy information supplied by theTPAs 14 along with the other payment information detail. As a result, company by company data and reports are generated even though the starting data from theTPAs 14 includes data related to a plurality of the subsidiaries orcompanies 12. - The flow charts herein illustrate the structure or the logic of the present invention as embodied in computer program software for execution on a computer, digital processor or microprocessor. Those skilled in the art will appreciate that the flow charts illustrate the structures of the computer program code elements, including logic circuits on an integrated circuit, that function according to the present technology. As such, the present technology is practiced in its essential embodiments by a machine component that renders the program code elements in a form that instructs a digital processing apparatus such as a computer to perform a sequence of function steps corresponding to those shown in the flow diagrams.
- It will be appreciated by those of ordinary skill in the pertinent art that the functions of several elements may, in alternative embodiments, be carried out by fewer elements, or a single element. Similarly, in some embodiments, any functional element may perform fewer, or different, operations than those described with respect to the illustrated embodiment. Also, functional elements (e.g., modules, tools, databases, interfaces, computers, servers and the like) described as distinct for purposes of illustration may be incorporated within other functional elements in a particular implementation.
- While the invention has been described with respect to preferred embodiments, those skilled in the art will readily appreciate that various changes and/or modifications may be made to the invention without departing from the spirit or scope of the invention as defined by the appended claims.
Claims (21)
1-10. (canceled)
11. A system for maintaining an escrow account associated with a third party administrator or TPA, the system comprising:
(a) a capture tool that provides a company with an ability to:
(i) receive, format and compile data files from the TPA;
(ii) receive, format and compile data files from a bank holding the escrow account; and
(iii) create relational databases interrelating records in the data files by the TPA, the escrow account and claim numbers; and
(b) a reconciliation tool that provides the company with an ability to:
(i) analyze the databases created by the capture tool; and
(ii) identify claims that are outstanding against the escrow account in order to insure efficient funding of the escrow account.
12. A system as recited in claim 11 , further comprising an administration tool, the administration tool providing the company with an ability to coordinate the processing of the capture tool and reconciliation tool as well as generate a report summarizing the outstanding claims.
13. A system as recited in claim 12 , wherein the administration tool further provides the company with an ability to generate a report summarizing money reconciled by the reconciliation tool, pending transactions, recoveries, unmatchable funds, funds reconciled outside the system and losses paid to claimants.
14. A system as recited in claim 12 , wherein the administration tool further provides the company with an ability to generate a report substantially in real-time including a claim identifier, a policy number and a check payment detail such that the company can verify accuracy of a payment request.
15. A system as recited in claim 11 , wherein the reconciliation tool further provides the company with an ability to monitor progress of transactions to confirm funding of the escrow account.
16. A system as recited in claim 15 , wherein the reconciliation tool further provides the company with an ability to confirm that the transactions result in funds being sent to the escrow account of the bank.
17. A system as recited in claim 16 , wherein the company is part of a holding company system that has a plurality of such companies, each company having respective transactions associated therewith such that the system segregates data related to the plurality of the companies based upon policy data supplied by the TPA.
18. A system for maintaining an escrow account associated with an insurance third party administrator (TPA), the system comprising:
a holding company having a plurality of insurance carriers, each insurance carrier having respective transactions associated therewith, the transactions being related to a claim of a respective holder of an insurance policy issued by the insurance carrier,
wherein the holding company includes:
(a) a capture tool that provides the insurance carrier with an ability to:
(i) receive, format and compile TPA data files from the TPA;
(ii) segregate data in the TPA data files related to the plurality of the insurance carriers based upon insurance policy data supplied in the TPA data files by the TPA;
(iii) receive, format and compile bank data files from a bank holding the escrow account; and
(iv) create relational databases interrelating records in the TPA and bank data files by the TPA, the escrow account and claim numbers; and
(b) a reconciliation tool that provides the insurance carriers with an ability to:
(i) analyze the relational databases created by the capture tool; and
(ii) identify claims that are outstanding against the escrow account in order to insure efficient funding of the escrow account, wherein the outstanding claims are identified by a check number, amount, date, and insurance claim number.
19. A system as recited in claim 18 , wherein the reconciliation tool further provides the insurance carrier with an ability to monitor progress of transactions to confirm funding of the escrow account.
20. A system as recited in claim 19 , wherein the reconciliation tool further provides the insurance carrier with an ability to confirm that the transactions result in funds being sent to the escrow account of the bank.
21. A system as recited in claim 18 , further comprising an administration tool, the administration tool providing the insurance carrier with an ability to coordinate processing of the capture tool and reconciliation tool as well as generate a report summarizing the outstanding claims.
22. A system as recited in claim 21 , wherein the administration tool further provides the insurance carrier with an ability to generate a report summarizing money reconciled by the reconciliation tool, pending transactions, recoveries, unmatchable funds, funds reconciled outside the system, and losses paid to claimants.
23. A system as recited in claim 21 , wherein the administration tool further provides the insurance carrier with an ability to generate a report substantially in real-time including a claim identifier, a policy number and a check payment detail such that the insurance carrier can verify accuracy of a payment request.
24. A system for maintaining an escrow account for an insurance carrier in a network in communication with a bank, a third party administrator (TPA), and the insurance carrier, the system comprising:
(a) a capture tool computer connected to the network for providing the insurance carrier with an ability to:
(i) receive funding requests from a TPA client computer of the TPA via the network, each fund request being an electronic record including a claim number, an amount, a check number and a check date;
(ii) format and compile TPA data files based on the funding requests;
(ii) receive, format and compile bank data files from a bank client computer of the bank holding the escrow account;
(iii) create relational databases interrelating records in the TPA and bank data files according to the TPA, the escrow account and claim numbers; and
(iv) approve the fund requests based upon the respective claim number, the amount, the check number, and the check date; and
(b) a reconciliation tool computer connected to the network for providing the insurance carrier with an ability to:
(i) analyze the relational databases created by the capture tool computer; and
(ii) identify claims that are outstanding against the escrow account in order to insure efficient funding of the escrow account.
25. A system as recited in claim 24 , wherein the capture tool computer further provides the insurance carrier with an ability to monitor clearance of funds from the escrow account such that a second fund request for a same claim number, amount, check number or date is rejected
26. A system as recited in claim 25 , wherein monitoring includes daily tracking of a total of outstanding payments to be made from the escrow account so that a balance of the escrow account is minimized.
27. A system as recited in claim 24 , further comprising an administration tool computer connected to the network, the administration tool computer providing the insurance carrier with an ability to coordinate processing of the capture tool computer and reconciliation tool computer as well as generate a report summarizing the outstanding claims.
28. A system as recited in claim 27 , wherein the administration tool computer further provides the insurance carrier with an ability to: generate a report summarizing money reconciled by the reconciliation tool, pending transactions, recoveries, unmatchable funds, funds reconciled outside the system and losses paid to claimants; generate a report substantially in real-time including a claim identifier, a policy number and a check payment detail such that the insurance carrier can verify accuracy of a payment request; and monitor progress of transactions to confirm funding of the escrow account.
29. A system as recited in claim 27 , wherein the capture tool computer, reconciliation tool computer, and administration tool computer are embodied in a server.
30. A system as recited in claim 24 , wherein the reconciliation tool computer further provides the insurance carrier with an ability to confirm that the transactions result in funds being sent to the escrow account of the bank.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US12/484,918 US20090254381A1 (en) | 2005-06-22 | 2009-06-15 | System for maintaining an escrow account for reimbursing administrators of payments |
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US69327205P | 2005-06-22 | 2005-06-22 | |
US11/472,933 US7567938B1 (en) | 2005-06-22 | 2006-06-22 | Method for reimbursing administrators of payments |
US12/484,918 US20090254381A1 (en) | 2005-06-22 | 2009-06-15 | System for maintaining an escrow account for reimbursing administrators of payments |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US11/472,933 Division US7567938B1 (en) | 2005-06-22 | 2006-06-22 | Method for reimbursing administrators of payments |
Publications (1)
Publication Number | Publication Date |
---|---|
US20090254381A1 true US20090254381A1 (en) | 2009-10-08 |
Family
ID=40887343
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US11/472,933 Active 2026-12-26 US7567938B1 (en) | 2005-06-22 | 2006-06-22 | Method for reimbursing administrators of payments |
US12/484,918 Abandoned US20090254381A1 (en) | 2005-06-22 | 2009-06-15 | System for maintaining an escrow account for reimbursing administrators of payments |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US11/472,933 Active 2026-12-26 US7567938B1 (en) | 2005-06-22 | 2006-06-22 | Method for reimbursing administrators of payments |
Country Status (1)
Country | Link |
---|---|
US (2) | US7567938B1 (en) |
Cited By (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20110202372A1 (en) * | 2010-02-12 | 2011-08-18 | Assets Quest, Inc. | Method and system for estimating unpaid claims |
US20110213699A1 (en) * | 2009-09-27 | 2011-09-01 | Johnson Timothy P | Consumer-Managed Escrow Accounts |
US20130144734A1 (en) * | 2011-12-06 | 2013-06-06 | Richard Scott Perkins | Money transfer system using pre-funded escrow |
US9473588B2 (en) | 2012-09-13 | 2016-10-18 | Alibaba Group Holding Limited | Data processing method and system |
US9626701B2 (en) | 2012-05-23 | 2017-04-18 | Paynearme, Inc. | System and method for facilitating cash payment transactions using a mobile device |
US10057313B2 (en) | 2015-10-02 | 2018-08-21 | Hartford Fire Insurance Company | System to dynamically adjust request values at a back-end application server |
US10192407B2 (en) | 2014-01-10 | 2019-01-29 | Handle Financial, Inc. | Systems and methods for cash payments for online gaming |
US10592792B2 (en) | 2011-04-14 | 2020-03-17 | Handle Financial, Inc. | Systems and methods for barcode translation |
Families Citing this family (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8442840B2 (en) * | 2006-02-14 | 2013-05-14 | Tomas G. Menocal | Transparent healthcare transaction management system |
US20100088125A1 (en) * | 2008-10-03 | 2010-04-08 | Vaughan David A | System and Method for Automation and Management of Insurance Claims Processing and Post Placement Transactions |
US8799026B2 (en) * | 2009-12-16 | 2014-08-05 | Hartford Fire Insurance Company | System for funding third-party-administered losses |
Citations (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20020007335A1 (en) * | 2000-03-22 | 2002-01-17 | Millard Jeffrey Robert | Method and system for a network-based securities marketplace |
US20020035488A1 (en) * | 2000-04-03 | 2002-03-21 | Anthony Aquila | System and method of administering, tracking and managing of claims processing |
US20020184163A1 (en) * | 2001-05-31 | 2002-12-05 | Lotter Robert A. | Shared insurance industry system for non-disruptive enhancement and substitution of insurance transaction processing |
US20040193540A1 (en) * | 2001-12-05 | 2004-09-30 | Brown Owen H. | Selective escrow using electronic funds transfer |
US20040204963A1 (en) * | 2003-03-07 | 2004-10-14 | Klueh Kevin R. | Healthcare payer organization and provider organization information exchange system |
US20040249666A1 (en) * | 2003-06-09 | 2004-12-09 | Napolitano Thomas S. | Healthcare system and a method of implementing same |
US7136840B2 (en) * | 2001-04-20 | 2006-11-14 | Intertrust Technologies Corp. | Systems and methods for conducting transactions and communications using a trusted third party |
US7386518B2 (en) * | 2003-12-16 | 2008-06-10 | Pitney Bowes Inc. | Method and system for facilitating transactions |
US7464057B2 (en) * | 2001-03-30 | 2008-12-09 | Citibank, N.A. | Method and system for multi-currency escrow service for web-based transactions |
US7464859B1 (en) * | 2004-12-17 | 2008-12-16 | Fred Hawkins | Reimbursement process and processor for conducting a financial transaction |
Family Cites Families (12)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5950169A (en) | 1993-05-19 | 1999-09-07 | Ccc Information Services, Inc. | System and method for managing insurance claim processing |
US5930759A (en) | 1996-04-30 | 1999-07-27 | Symbol Technologies, Inc. | Method and system for processing health care electronic data transactions |
US7016856B1 (en) | 1996-12-13 | 2006-03-21 | Blue Cross Blue Shield Of South Carolina | Automated system and method for health care administration |
US6343271B1 (en) | 1998-07-17 | 2002-01-29 | P5 E.Health Services, Inc. | Electronic creation, submission, adjudication, and payment of health insurance claims |
US6341265B1 (en) | 1998-12-03 | 2002-01-22 | P5 E.Health Services, Inc. | Provider claim editing and settlement system |
US20050033604A1 (en) | 1999-07-13 | 2005-02-10 | Mitan Technologies, Llc | Method and apparatus for settling claims between health care providers and third party payers |
US20040231018A1 (en) | 2000-04-17 | 2004-11-18 | Olson A. Wayne | Escrow management structure |
US20020152097A1 (en) | 2000-09-01 | 2002-10-17 | Javors Jonathan R. | Method of administration and health management |
US8204766B2 (en) | 2001-08-15 | 2012-06-19 | Meridian Enterprises Corporation | Insurance claim payment card system |
US20030187695A1 (en) | 2002-04-01 | 2003-10-02 | Drennan Hollis Deon | ACSAS (automated claims settlement acceleration system) |
EP1547033A1 (en) | 2002-08-16 | 2005-06-29 | Internet Payments Patents Limited | A funds transfer method and system |
US20050080692A1 (en) | 2003-10-10 | 2005-04-14 | Amarjit Padam | System and method for distributing payments between multiple accounts |
-
2006
- 2006-06-22 US US11/472,933 patent/US7567938B1/en active Active
-
2009
- 2009-06-15 US US12/484,918 patent/US20090254381A1/en not_active Abandoned
Patent Citations (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20020007335A1 (en) * | 2000-03-22 | 2002-01-17 | Millard Jeffrey Robert | Method and system for a network-based securities marketplace |
US20020035488A1 (en) * | 2000-04-03 | 2002-03-21 | Anthony Aquila | System and method of administering, tracking and managing of claims processing |
US7464057B2 (en) * | 2001-03-30 | 2008-12-09 | Citibank, N.A. | Method and system for multi-currency escrow service for web-based transactions |
US7136840B2 (en) * | 2001-04-20 | 2006-11-14 | Intertrust Technologies Corp. | Systems and methods for conducting transactions and communications using a trusted third party |
US20020184163A1 (en) * | 2001-05-31 | 2002-12-05 | Lotter Robert A. | Shared insurance industry system for non-disruptive enhancement and substitution of insurance transaction processing |
US20040193540A1 (en) * | 2001-12-05 | 2004-09-30 | Brown Owen H. | Selective escrow using electronic funds transfer |
US20040204963A1 (en) * | 2003-03-07 | 2004-10-14 | Klueh Kevin R. | Healthcare payer organization and provider organization information exchange system |
US20040249666A1 (en) * | 2003-06-09 | 2004-12-09 | Napolitano Thomas S. | Healthcare system and a method of implementing same |
US7386518B2 (en) * | 2003-12-16 | 2008-06-10 | Pitney Bowes Inc. | Method and system for facilitating transactions |
US7464859B1 (en) * | 2004-12-17 | 2008-12-16 | Fred Hawkins | Reimbursement process and processor for conducting a financial transaction |
Cited By (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20110213699A1 (en) * | 2009-09-27 | 2011-09-01 | Johnson Timothy P | Consumer-Managed Escrow Accounts |
US20110202372A1 (en) * | 2010-02-12 | 2011-08-18 | Assets Quest, Inc. | Method and system for estimating unpaid claims |
US8315888B2 (en) * | 2010-02-12 | 2012-11-20 | Assets Quest, Inc. | Method and system for estimating unpaid claims |
US10592792B2 (en) | 2011-04-14 | 2020-03-17 | Handle Financial, Inc. | Systems and methods for barcode translation |
US20130144734A1 (en) * | 2011-12-06 | 2013-06-06 | Richard Scott Perkins | Money transfer system using pre-funded escrow |
US9626701B2 (en) | 2012-05-23 | 2017-04-18 | Paynearme, Inc. | System and method for facilitating cash payment transactions using a mobile device |
US9473588B2 (en) | 2012-09-13 | 2016-10-18 | Alibaba Group Holding Limited | Data processing method and system |
US10708384B2 (en) | 2012-09-13 | 2020-07-07 | Alibaba Group Holding Limited | Data processing method and system |
US10192407B2 (en) | 2014-01-10 | 2019-01-29 | Handle Financial, Inc. | Systems and methods for cash payments for online gaming |
US10854046B2 (en) | 2014-01-10 | 2020-12-01 | Handle Financial, Inc. | Systems and methods for cash payments for online gaming using location |
US10057313B2 (en) | 2015-10-02 | 2018-08-21 | Hartford Fire Insurance Company | System to dynamically adjust request values at a back-end application server |
Also Published As
Publication number | Publication date |
---|---|
US7567938B1 (en) | 2009-07-28 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US7567938B1 (en) | Method for reimbursing administrators of payments | |
US8423450B2 (en) | System and method for processing data pertaining to financial assets | |
US8494927B2 (en) | Method for providing a web-based payroll and payroll related software as a service | |
US7593889B2 (en) | System and method for processing data pertaining to financial assets | |
US7340424B2 (en) | System and method for facilitating sale of a loan to a secondary market purchaser | |
US7835921B1 (en) | Patient credit balance account analysis, overpayment reporting and recovery tools | |
US7860787B2 (en) | System and method for modifying attribute data pertaining to financial assets in a data processing system | |
US8065211B2 (en) | System and method for creating and tracking agreements for selling loans to a secondary market purchaser | |
US20050102226A1 (en) | System and method of accounting for mortgage related transactions | |
US11935133B2 (en) | System and method for consolidation, reconciliation and payment management | |
US20050080722A1 (en) | Online system for delivery of loans to a secondary market purchaser | |
JP2003532212A (en) | Receivables web-based method and system | |
JP2003532229A (en) | Method and apparatus for managing receivables remittance processing | |
JP2003532230A (en) | Method, apparatus and computer program for managing an accounting system interface | |
US20060047600A1 (en) | Method and system for borrowing base certificate administration | |
US20130246303A1 (en) | Corporate actions automation system and method | |
US8682766B1 (en) | Method for providing comprehensive ACH vendor services | |
AU2004273117B2 (en) | Computer-based system for transactions processing | |
US20050114253A1 (en) | Systems and methods for automated transactions processing | |
US20060116906A1 (en) | Health care cash management and accounts receivable factoring | |
US20220292474A1 (en) | Payment Processing of Medical Services | |
JP2003533773A (en) | Accounts receivable claim management method and device | |
JP2002230298A (en) | Financial system for insured medical fee credit |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: ARCH CAPITAL GROUP (U.S.) INC., NEW YORK Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:FREDERICKSON, F. SCOTT;LARUSSO, DAVID;REEL/FRAME:022828/0845 Effective date: 20060621 |
|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |