Patent Application
20210398117
Embodiments described herein generally relate to data processing and in particular, but without limitation, to an application data validation programming interface.
Billions of electronic transactions occur every day and many are dependent on having valid and properly formatted data. If a transaction is improperly formatted or contains data that may not be verified, the transaction may fail. In some instances, transactions are batched together in a single data file because it is not practical or possible to process each transaction in real-time. Accordingly, some entities may not be aware of a failure of a transaction until the next day, assuming that the files are batched daily.
In the drawings, which are not necessarily drawn to scale, like numerals may describe similar components in different views. Like numerals having different letter suffixes may represent different instances of similar components. Some embodiments are illustrated by way of example, and not limitation, in the figures of the accompanying drawings in which:
Computing systems are responsible for processing billions of financial transactions per day. In some instances, technical limitations prevent companies from knowing if a transaction has failed until much later (e.g., a day) after the transaction was submitted for processing. Often, the transactions are submitted in accordance with one or more defined file formats. For example, the National Automated Clearly House Association (NACHA) defines the format for transactions that use the automated clearing house (ACH) electronic network. An ACH file may include thousands of entries that detail transfers of money between accounts based on routing and account numbers. A submitted ACH file may not be processed until the end of the day. Because of the non-real-time processing of ACH files, many companies find out the errors the next day. Accordingly, when errors occur (e.g., insufficient funds) it may take another day before a modified ACH file is generated and submitted. In other words, there is no technical mechanism to electronically determine if one or more transfers will fail for insufficient funds before submitting the ACH file.
Presented here are systems and methods that provide a technical solution to the problem described above. More specifically, this disclosure details an electronic service provided as an application programming interface (API) for technical validation of an ACH file with respect to fund verification—prior to the ACH file having been submitted for processing. And although the disclosure focuses on ACH files, the methods may be similarly applied to other data structures and financial transaction formats in which fund verification may be warranted before submitting a file for processing.
An API may provide an interface for the exchange of a data between two computing systems or programs. In some instances, when the API is network accessible, the API may be considered a web API. Web server 106 may provide functions—such as by implementing a Representational state transfer API (RESTful API) via properly formatted hypertext transfer protocol (HTTP) messages—to process and respond to API calls according to API 104. An API request may come from external devices (e.g., requesting computing device 116) as well as from internal programs (e.g., web applications of electronic data verification service 102). For example, requesting computing device 116 may format an API call according to API 104 to send requesting data structure 112 to electronic data verification service 102 for processing. In response to the API call, electronic data verification service 102 may transmit a response message that contains response data structure 114.
In various examples, the servers and components illustrated in
Data used in electronic data verification service 102 may be organized and stored in a variety of manners. For convenience, the organized collection of data is described herein as data store 110. The specific storage layout and model used in data store 110 may take a number of forms—indeed, data store 110 may utilize multiple models. Data store 110 may be, but is not limited to, a relational database (e.g., SQL), non-relational database (NoSQL) a flat file database, object model, document details model, or a file system hierarchy. Data store 110 may store data on one or more storage devices (e.g., a hard disk, random access memory (RAM), etc.). The storage devices may be in standalone arrays, part of one or more servers, and may be located in one or more geographic areas. The storage devices may be part of different computing systems.
A database management system (DBMS) may be used to access the data stored within data store 110. The DBMS may offer options to search data store 110 using a query and then return data in the data store 110 that meets the criteria in the query. For example, a SQL query may be utilized to retrieve balance information for a given account number. The DBMS may operate on one or more of the components of electronic data verification service 102.
Furthermore, although API 104, web server 106, data store 110, and verification component 108 are illustrated being part of a single entity (electronic data verification service 102) different architectural arrangements may be used. For example, verification component 108 may query a data store that is not co-located with verification component 108. Similarly, web server 106 may be implemented as an array of computing servers that do not perform the functions of verification component 108.
In an example, electronic data verification service 102 is a service provided by a financial institution. One or more routing numbers may have been assigned to the financial institution. Furthermore, within data store 110, the financial institution may have account data (e.g., available funds) for a number of accounts. Accordingly, given a requested transfer amount, the financial institution may be able to calculate if there are sufficient funds for the transfer.
Requesting computing device 116 may be part of a payroll system. A company may use the payroll system to determine the amount of money needed to pay the company's employees based on information received from the company (e.g., number of hours worked, hourly rate, etc.). As part of this process, the payroll system may generate an ACH data file to initiate the transfer of money between financial accounts.
The payroll system may not know, however, if there are sufficient funds in the financial accounts to cover the transfer. In order to electronically verify the funds, requesting computing device 116 may transmit the AGI file (e.g., requesting data structure 112) to electronic data verification service 102. Electronic data verification service 102 may receive requesting data structure 112 via an API call or as part of a file upload provided by web server 106. Requesting data structure 112 may be encrypted and/or the API call may be made over a secured communication link (e.g., Secured Socket Layer).
In some instances, requesting computing device 116 may authenticate with electronic data verification service 102 before, or at the time of, submitting requesting data structure 112. Authentication may include providing credentials (e.g., token, username/password combination) to electronic data verification service 102. The credentials may be provided as part of the API call to electronic data verification service 102.
Verification component 108 may process requesting data structure 112 to determine if there are sufficient funds in originating accounts contained with the ACH file to cover a transfer. ACH files have a defined structure made up of five main records: (1) File Header Record; (2) one or more Batch Header Records: (3) one or more PPD Entry Detail Records; (4) one or more Batch Control Records; and (5) a file control record. Each of these records includes precise formatting requirements such as 94 characters per line and what data is to be placed at each character (e.g., character position 1 of a PPD entry is always a ‘6’). Among other information, the ACH file details routing and account numbers and amounts to be transferred from such accounts. For example, a batch control record indicates the total amount of credits and debits to an account for all associated PPD entry records.
Because of the defined format, verification component 108 may parse an ACH file and determine, for a given account, the total amount of money to be debited across the entire ACH file. Additionally, as electronic data verification service 102 has access to account data for a number of accounts, verification component 108 may calculate if there are sufficient funds for the defined debits. In some examples, verification component 108 may ignore transfer amounts in the ACH file that uses routing numbers not associated with the financial institution.
Verification component 108 may then parse the ACH file. Parsing may include generating a list of data entries such as [routing number, account number, amount] tuples. The information in the tuples may be ascertained by looking at the locations of such information as defined in the ACH file format, in an example. The list of entries may be iterated through to determine (1) if the routing number is part of the same financial institution associated with electronic data verification service 102 and (2) for the accounts that are associated with the financial institution, if there are sufficient funds to cover the indicated debit in the ACH file.
To determine if the routing number is associated with the financial institution, a query may be made to data store 110. Data store 110 may store a list of routing numbers for which electronic data verification service 102 may access account balance data. If a routing number is stored in data store 110, it may be considered valid.
Web server 106 may present the results to the requesting computing device 116 using an interface such as depicted in
Verification may also include looking across different banks and financial institutions in an ACH file. For example, demand deposit accounts (DDA) in the ACH may be associated with different banks or financial institutions. In an example, an ACH file may be examined to review one DDA for the needed funds, but then debiting another DDA for the proceeds.
As one recalls, the processing of the ACH by verification component 108 occurs prior to the ACH file being processed as an actual transfer. In some examples, if verification component 108 determines all accounts in the ACH file have sufficient funds, electronic data verification service 102 may initiate the transfer. In other examples, the ACH file may be resubmitted by requesting computing device 116 (or a different computing device) to initiate the transfer.
Web interface 202 is an example of a layout for presenting the results. Other layouts and features may be used without departing from the scope of this disclosure. For example, a column indicating whether or not the routing number is valid may be used. Another column may indicate the amount of funds available in the account. A user interface element may be used to filter or sort the results (e.g., show only accounts with insufficient funds).
Response package 300 may be used by electronic data verification service 102 to generate web interface 202 in various examples. For example, electronic data verification service 102 may internally invoke API 104 and receive a response package. The response package may be parsed and presented according to a defined layout (e.g., web interface 202). In other words, the same API call, and corresponding response package may be used by web server 106 as is used by requesting computing device 116. Thus, instead of the web server 106 needing its own ACH verification logic, API 104 may be used.
Additionally, having the verification logic contained in API 104 may allow further computing systems to submit ACH files for verification without a user. This may also permit those computing systems to use their own web servers to generate reports, web interfaces, etc., based on the response packages from API 104. Accordingly, “white label” ACH verification services may be provided by those computing systems.
API 104 may provide a function for verifying sufficiency of funds without an ACH file. For example, API 104 may respond to a request that submits a routing number, account number, and amount as parameters. A response package similar response package 300 may be transmitted back to a requesting device with the results.
At operation 402, a structure data file may be received from a requesting computing device. The structured data file may be received at a computing system such as electronic data verification service 102. The structured data file may be received over an API. In an example, the structured data file is received in response to activation of an input portion of a user interface. The structured data file may include set of defined data portions. A first portion of the set of defined data portion may include, a first attribution identifier, a first account identifier, and a first amount. The attribution identifier may be a routing number of a financial institution and the account identifier may be an account number at the financial institution. The structured data file may be formatted as an ACH file.
At operation 404, it may be determined that the first attribution identifier is included in a set of permitted attribution identifiers. A permitted attribution identifier may be an identifier stored as associated with the financial institution. The set may include a set of routing numbers used by the financial institution. Determining whether the first attribution identifier is permitted may include querying a data storage device.
After the determining, a data store may be queried using the first attribution identifier and the first account identifier to retrieve a current amount associated with the first account identifier (operation 406). A calculation may determine that the current amount is at least equal to the first amount (operation 408).
At operation 410, a first electronic message may be formatted that indicates a validated calculation for the first portion. Formatting may include inserting the first attribution identifier, the first account identifier; the first amount, the current amount, and a result of the calculating into a data structure. The data structure may be formatted as a JSON message.
At operation 412 the first electronic response message may be presented to the requesting computing device. Presenting may include presenting a user interface that includes an output portion, the output portion identifying the first attribution identifier, the first account identifier, and data representing the first electronic response message. For example, a table layout may be presented on a webpage that includes the data in the response message. Presenting may also include transmitting the data structure to the requesting computing device.
A second portion of the defined data portions may include a second attribution identifier, a second account identifier, and a second amount. The operations may further include, based on determining that the second attribution identifier is not included in the set of permitted attribution identifiers, formatting a second electronic response message that indicates a non-validated calculation for the second portion. The first and second response messages may be transmitted as part of the same data structure, in an example. Indicating a non-valid calculation may include placing a “false” or other predetermined signifier as the value for a parameter in the data structure (e.g., “validated:0”).
Embodiments described herein may be implemented in one or a combination of hardware, firmware, and software. Embodiments may also be implemented as instructions stored on a machine-readable storage device, which may be read and executed by at least one processor to perform the operations described herein. A machine-readable storage device may include any non-transitory mechanism for storing information in a form readable by a machine (e.g., a computer). For example, a machine-readable storage device may include read-only memory (ROM), random-access memory (RAM), magnetic disk storage media, optical storage media, flash-memory devices, and other storage devices and media.
Examples, as described herein, may include, or may operate on, logic or a number of components, modules, or mechanisms. Modules may be hardware, software, or firmware communicatively coupled to one or more processors in order to carry out the operations described herein. Modules may be hardware modules, and as such modules may be considered tangible entities capable of performing specified operations and may be configured or arranged in a certain manner. In an example, circuits may be arranged (e.g., internally or with respect to external entities such as other circuits) in a specified manner as a module. In an example, the whole or part of one or more computer systems (e.g., a standalone, client or server computer system) or one or more hardware processors may be configured by firmware or software (e.g., instructions, an application portion, or an application) as a module that operates to perform specified operations. In an example, the software may reside on a machine-readable medium. In an example, the software, when executed by the underlying hardware of the module, causes the hardware to perform the specified operations. Accordingly, the term hardware module is understood to encompass a tangible entity, be that an entity that is physically constructed, specifically configured (e.g., hardwired), or temporarily (e.g., transitorily) configured (e.g., programmed) to operate in a specified manner or to perform part or all of any operation described herein. Considering examples in which modules are temporarily configured, each of the modules need not be instantiated at any one moment in time. For example, where the modules comprise a general-purpose hardware processor configured using software; the general-purpose hardware processor may be configured as respective different modules at different times. Software may accordingly configure a hardware processor, for example, to constitute a particular module at one instance of time and to constitute a different module at a different instance of time. Modules may also be software or firmware modules, which operate to perform the methodologies described herein.
Example computer system 500 includes at least one processor 502 (e.g., a central processing unit (CPU), a graphics processing unit (GPU) or both, processor cores, compute nodes, etc.), a main memory 504 and a static memory 506, which communicate with each other via a link 508 (e.g., bus). The computer system 500 may further include a video display unit 510, an alphanumeric input device 512 (e.g., a keyboard), and a user interface (UI) navigation device 514 (e.g., a mouse). In one embodiment, the video display unit 510, input device 512 and UI navigation device 514 are incorporated into a touch screen display. The computer system 500 may additionally include a storage device 516 (e.g., a drive unit), a signal generation device 518 (e.g., a speaker), a network interface device 520, and one or more sensors (not shown), such as a global positioning system (GPS) sensor, compass, accelerometer, or other sensor.
The storage device 516 includes a machine-readable medium 522 on which is stored one or more sets of data structures and instructions 524 (e.g., software) embodying or utilized by any one or more of the methodologies or functions described herein. The instructions 524 may also reside, completely or at least partially, within the main memory 504, static memory 506, and/or within the processor 502 during execution thereof by the computer system 500, with the main memory 504, static memory 506, and the processor 502 also constituting machine-readable media.
While the machine-readable medium 522 is illustrated in an example embodiment to be a single medium, the term “machine-readable medium” may include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) that store the one or more instructions 524. The term “machine-readable medium” shall also be taken to include any tangible medium that is capable of storing, encoding or carrying instructions for execution by the machine and that cause the machine to perform any one or more of the methodologies of the present disclosure or that is capable of storing, encoding or carrying data structures utilized by or associated with such instructions. The term “machine-readable medium” shall accordingly be taken to include, but not be limited to, solid-state memories, and optical and magnetic media. Specific examples of machine-readable media include non-volatile memory, including but not limited to, by way of example, semiconductor memory devices (e.g., electrically programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM)) and flash memory devices; magnetic disks such as internal hard disks and removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks.
The instructions 524 may further be transmitted or received over a communications network 526 using a transmission medium via the network interface device 520 utilizing any one of a number of well-known transfer protocols (e.g., HTTP). Examples of communication networks include a local area network (LAN), a wide area network (WAN), the Internet, mobile telephone networks, plain old telephone (POTS) networks, and wireless data networks (e.g., 3G, and 4G LTE/LTE-A or WiMAX networks). The term “transmission medium” shall be taken to include any intangible medium that is capable of storing, encoding, or carrying instructions for execution by the machine, and includes digital or analog communications signals or other intangible medium to facilitate communication of such software.
The above detailed description includes references to the accompanying drawings, which form a part of the detailed description. The drawings show, by way of illustration, specific embodiments that may be practiced. These embodiments are also referred to herein as “examples.” Such examples may include elements in addition to those shown or described. However, also contemplated are examples that include the elements shown or described. Moreover, also contemplate are examples using any combination or permutation of those elements shown or described (or one or more aspects thereof), either with respect to a particular example (or one or more aspects thereof), or with respect to other examples (or one or more aspects thereof) shown or described herein.
This patent application claims the benefit of U.S. Provisional Patent Application No. 62/440,358, filed Dec. 29, 2016, entitled “DATA VALIDATION APPLICATION PROGRAMMING INTERFACE”, which is incorporated by reference herein in its entirety.
| Number | Date | Country | |
|---|---|---|---|
| 62440358 | Dec 2016 | US |
