Extending PCM Automation to Third-Party Systems
Written by David Peterson
In this fourth and final installment in our series covering the capabilities of Payment Case Manager (PCM)—the only end-to-end tool for secure communication of payment disputes (read Part 1, Part 2, and Part 3)—the focus shifts from the features of PCM and its advantages to FIs of all sizes and types to how PCM can interact with other systems. The more PCM interconnects with third-party systems, the more positively impactful PCM’s level of automation and subsequent cost savings becomes.
While there are extensive API capabilities built into PCM as documented further in this article, the tool was created to be used standalone and does not require an interface with any external system. This is critically important, particularly when examining the efforts to interface to systems that larger FIs operate. The larger the originating depository financial institution (ODFI), the more likely that the steps and approvals to create and execute an interface integration to some internal system to that FI becomes difficult—if not impossible. Therefore, the idea that bore PCM was to create a secure, web-based system that any FI could access using authorized access credentials from any web-enabled computer. PCM will, in fact, be used by FIs in that very mode.
The largest FIs are likely to have their own instance of PCM running in their own data center. Thus, an integration between a local PCM instance running locally and the rest of the PCM system will connect that FI to all other PCM participants. This ability for PCM to be installed locally for a large FI may be necessary to comply with expanded data security requirements.
There are two other types of integration interfaces available in PCM. One is an application programming interface (API), and the other is a file-based interface where data is imported or exported in a manner that can be used by an external system. Let’s first examine API interfaces.
Once FIs begin using PCM, they find that there are specific areas where additional automation will be greatly beneficial. APIs generally add value in the following categories:
- • User Access – Allow authorized users to access PCM from another credential secured access point. An example of this would be a single-sign on (SSO) to a central authentication app at an FI that individual employees access that then spawn to any authorized apps.
- • Client Access – One of the best features of PCM is the extensibility of PCM to corporate originators. The ODFI may have multiple connections to its corporate originators, so there are multiple opportunities for PCM to provide information that directly passes open cases to the originating companies that can provide the appropriate responses.
- • Payment Databases – Most FIs have a centralized location where payment data is archived. Using ACH as an example, there is great benefit if PCM would have access to ACH database to validate ACH data necessary for the operation of PCM for ACH disputes.
Let’s examine each of these interfaces.
The most basic and straightforward interface is the SSO. This involves an electronic “handshake” between two systems that allows an authenticated user on the “Identity Provider” to be granted privileges on the “Service Provider” without having to separately login. PCM uses a type of SSO called SAML2, a common interface format that is supported by most third-party systems. One of the best features supported by PCM is the ability to allow for access to PCM through the SSO for a user that has never previously logged into PCM.
Think about this—PCM might be used by 10,000 financial institutions. Even if there is only a handful of users per FI on average, that would still be a monumental effort to get those users created in PCM. What happens instead is PCM receives an SSO call from the third-party system and it shares information about the user including username, FI name, and a code that represents their level of permissions and/or authorizations from the calling system. This allows for PCM to register that user in PCM and assigns a level of permission and authority that aligns with the permissions from the calling system. The user is granted access and placed into a landing page in PCM appropriate to their security level, in a new browser window. The user can conduct the activity as appropriate in PCM and when they are finished, they can close the window and return to the calling application.
Access for FI clients can also involve an SSO. Take the example of an ODFI that is using PCM and wants their business customers to access PCM through the online treasury and/or cash management the ODFI provides. Similar to the aforementioned, an SSO to the cash management solution would enable authorized users of the online cash management solution to have a menu option that takes a user to the appropriate landing page of PCM.
Further options for how PCM can enable client access include the ability to interface PCM to secure email systems. If secure email is how an FI communicates non-public information to and from its business customers, PCM can create the appropriate secure email with the PCM case info for delivery to the business. Similarly, PCM can import and extract from a secure email coming from a company back to the FI, identify the response and connect the documentation provided to the PCM case. This enables the FI to automate between ODFI and receiving depository FI (RDFI), even if the connection to and from the business originator is not using the PCM user interface. Lastly, some FIs communicate with their originators via fax. While one of the main focuses of PCM is to eliminate faxes, in fact, it can interface with a fax service in the same fashion as described above for secure email.
APIs for payments databases can be extremely beneficial for the automation of payment disputes. Again, using ACH as the example, when a PCM ACH case is presented to an FI, one step they may likely take is to interrogate the ACH database to determine if the transaction in question originated from their systems. PCM can interface directly to an FI’s ACH database, eliminating the manual lookup of transactions. Further, each ODFI maintains a database of the originating companies on whose behalf the ODFI submits ACH files. Periodically, a request for information on an originator is received and the ODFI is obligated to provide contact information on the company. With an API into the ODFI’s originator database, these requests can be automated by PCM. These are just two examples of how PCM can interface with external payment databases.
Let’s turn our attention to file-based interfaces. Essentially, a file interface is the ability to import or export data that is coming from or going to an external system. File formats can be any custom type depending on the system involved, but there are several self-defining formats that are supported by PCM. These include: CSV (comma separated value), Excel, and XML (extensible markup language). While each of these are different, they have the same ability to be used for extracting data from one system and presenting to another where it can be consumed for the stated purpose. PCM supports file imports and exports as follows:
Data Importing
Creating Cases – a file can be created by a third-party system that contains the information necessary to create one or more cases within PCM. Once imported, cases can be processed no different than a manually created PCM case. Data importing is available for both ODFI and RDFI users.
Data Exporting
Creation of Manual Communication Methods – In the instance where a case is received by an FI via PCM but is not using PCM to communicate to the originator, PCM can create the necessary exported information suitable to be delivered external to PCM via fax or secure email.
Archival – Although PCM contains its own archival of all case data and activities, an FI or originator may want to export out of PCM for delivery to a third-party data archival system. PCM Supports this activity by exporting cases in a format that captures all of the relevant information on the case and details about case details by each party.
Exporting Completed Cases – Separate from the archival activity, an FI that receives a remediated case may want to deliver that case to an external system. An example of this is where a client helpdesk system initiated the case. When that case has been remediated and the requested documents have been returned, the FI wants the original entity requesting the case to be notified of its conclusion and present the documentation.
Fax Conversion
A unique feature of importing data that PCM supports is the conversion of faxes into cases. This is especially useful for large ODFIs in the instance where they are a member of PCM but few of the FIs directing cases to them have yet become members. The volume of daily faxes would cause a significant amount of manual effort to key into PCM. PCM supports the FI creating an export of the PDF documents that are the result of inbound faxes and uses optical character recognition (OCR) to interpret the fax and create a case. While not 100% accurate, the data entry required to repair any mis-identified fields in a fax-imported PCM case is a small fraction of the work to manually create cases from received faxes.
PCM is a complex system that must be flexible to adapt to the simplicity needed by a small financial institution while providing the robust features needed to serve the largest ODFIs. PCM achieves this by tapping into the many API and data interface options that are natively available in the Clearingworks platform. Using the parameter-driven tools endemic to Clearingworks, technical staff can easily create APIs and, more importantly, adjust APIs when interfaces require change. Software upgrades, database changes, and other factors cause APIs to have to be adjusted for them to continue operating as intended. Clearingworks makes this process easy and eliminates the need to do costly and time-consuming programming.
The ability to interface with third-party systems is a critical component that makes PCM the perfect solution for FIs and their business customers looking to automate payment disputes. Nacha estimates ACH disputes to cost the industry $96 million each year. PCM’s focus on automation through API and file interfaces enables the industry to take a ginormous bite out of that annual cost. And that is a task worthy of PCM’s automation.
RECENT BLOG POSTS
• Combining Automation and Human-Driven Analysis to Keep More Payments Electronic
• Learning Lockbox Lingo: What Is a Check and List Transaction?
