Bank: Mechanics Bank
Problem: Its anti-check fraud solution wouldn't work with a new cash management and online banking system.
Solution: Mechanics switched to a system that will integrate easily with the new technology.
Richmond, Calif.-based Mechanics Bank knew it needed a new anti-check-fraud solution. The community bank had determined that its positive pay platform, a proprietary product from Fiserv, its core system vendor, didn't offer enough flexibility to meet its changing needs. It lacked a sufficient interface with the new cash management and online banking system from Intuit that the $3 billion-asset bank was readying to install at press time.
"The convenience aspect was that Fiserv was fully integrated with our core system," says Michelle Monaco, vice president at Mechanics. "However, it was limited in features and functionality; some aspects of it were inefficient, and it only played nice with its own core." The check verification system would only accept files written in one format from corporate customers' accounts payable systems. [Fiserv's response: "We understand that not every solution is a perfect fit for every client, however we have strong anti-fraud and positive pay platforms that provide flexible options," says Dan Werner, senior vice president, risk & performance for bank solutions at Fiserv. "For clients using third-party systems, we can provide custom integration services, such as standard API messaging, to provide even more flexibility."]
Requiring that the new positive pay solution be deployed in-house considerably narrowed Mechanics' vendor choices. "A majority of our systems are installed on our servers; that gives us greater control, flexibility and some cost savings," Monaco says. Using an ASP can bar the client from touching the software; any customized suggestions may only come at the whim of the provider, or whenever the chosen vendor upgrades, she believes. Fiserv's Checkfree solution was out: the family-owned bank doesn't use Fiserv's ASP services for its core system. Metavante and FIS were ruled out for similar reasons.
ASD's Sand system, which the bank ultimately chose, comes with barcode technology that encrypts each check's identifying serial number, payee information and dollar amount. The barcode eliminates the typical requirement for customers to upload their "checks issued" files for verification purposes. It's similar to the UPC code found on supermarket products containing multiple lines of various widths. The customer simply downloads the bar-coding software, which places a barcode on the check during printing.
"When a check gets presented to the bank, it knows that customer is a positive pay customer because we've set him up that way, and it will look for every single item to ensure that it has that barcode on it," Monaco said. "If it doesn't, it will appear as an exception.
Also, Sand enables Mechanics to have a single-entry access point, due in part to an interface the bank is building for its new Intuit online banking platform. (Mechanics currently uses Fiserv for cash management.)
Plus, Sand enables mapping to any sort of abstract files from customers' payables solutions. "So it's flexible," Monaco said. Why go with a reseller? Monaco said Mechanics chose VSoft to implement Sand in part because the bank expects to tap VSoft's own financial solutions, including remote deposit capture, as well as its integration expertise.
Sand includes payee, traditional, reverse and ACH positive pay features, as well as reconciliation. Traditional positive pay lets the customer validate checks before payments are made. Payee name verification adds cross-referencing of the payee name to the audit of the check dollar amount and serial number. Reverse positive pay provides customers a list of items presented each day; they cross-reference the list with their records. The reconciliation component enables daily changes and cross-referencing: As transactions are presented to the customer's account, any adjustments or journal entries that need to be made to the customers' books are done as the transactions occur, instead of waiting to make corrections at the end of the month. This way, customers can address anomalies immediately and account for them in their books, whether it was a bookkeeping error or a check adjustment. The purpose is to catch mistakes, detect fraud or make modifications well before users do their regular, full month-end reconciliations.
Ordinary check fraud, such as altering payee names on checks, never seems to go away. "It's common," Monaco says. "Whether it's an employee, somebody the customer knows or someone they don't know. With the economic times the way they are, we're seeing people more desperate. But it's just something all financial institutions have to deal with."
