Case Study Financial Services
Building an In-House NACHA-to-EDI 820 Exchange on Informatica B2B for a Tier 1 Regional Bank
Replacing a third-party conversion dependency with a governed, in-house B2B data exchange stack
GlobalPay dependency retired — in-house NACHA-to-EDI 820 exchange live
Summary
aiDataWorks helped a Tier 1 regional bank build an in-house Informatica B2B foundation — PowerCenter, B2B Data Exchange, and Managed File Transfer — to replace its reliance on the third-party GlobalPay conversion service, centered on a NACHA-to-EDI-X12-4010 820 conversion pipeline. Mid-implementation, the team diagnosed and engineered a workaround for a critical Informatica DX 10.2HF2 installer defect (an SSL / SQL Server 16 incompatibility) that could have derailed the bank's fixed migration timeline. The engagement delivered a working first prototype of the conversion pipeline and gave the bank in-house capability it could extend into a service offering for its own customers.
The challenge
- Dependent on a third-party converter. The bank relied on a third-party application, GlobalPay, to convert partner NACHA files into EDI-X12-4010 820 format rather than handling the conversion in-house.
- No B2B product stack in place. None of Informatica's B2B products — PowerCenter, B2B Data Exchange, or B2B Managed File Transfer — were set up on the bank's TEST or PROD environments, so the foundation had to be built from scratch.
- Critical installer failure against a fixed deadline. During setup, the B2B Data Exchange 10.2HF2 installer failed to connect to the database, blocking progress against a migration deadline that could not move.
The solution
How we built it
Standing up the B2B stack
- Stood up the full Informatica B2B product stack — PowerCenter, B2B Data Exchange, and B2B Managed File Transfer — across both TEST and PROD environments.
- Built the foundation from the ground up, since no prior B2B stack existed at the bank for this use case.
- Configured PowerExchange and Informatica Data Quality (IDQ) alongside the core B2B components to support the file-conversion workflow.
Diagnosing and fixing the installer defect
- Traced the B2B Data Exchange 10.2HF2 installer's database connection failure to a known product bug: DX 10.2HF2 fails on Windows Server 16 when SSL encryption is enabled on SQL Server 16.
- Raised an Emergency Bug Fix (EBF) request with Informatica while engineering a workaround in parallel, so the fixed migration deadline was not put at risk.
- Applied the workaround: disabled SSL, installed DX, took the environment down, re-enabled SSL, added
SSL=Trueto the DX configuration, replaced an ODBC jar file in the DX library, and restarted services. - Documented the fix as a reusable install/SSL procedure for future DX 10.2HF2 deployments.
Building the NACHA-to-EDI 820 pipeline
- Received partner NACHA batch files over GlobalScape SFTP/SCP as the inbound transport.
- Used a DT Parser to convert the incoming NACHA file into XML.
- Applied a DT Mapper to transform the parsed XML into the target structure.
- Serialized the transformed data into EDI-X12-4010 820 format and delivered it back out over GlobalScape SFTP/SCP.
- Added monitor-flag checks and email notifications across the pipeline so failures and completions were visible without manual polling.
Outcomes
- The bank replaced its dependency on the third-party GlobalPay conversion service with an in-house Informatica B2B stack it owns and controls.
- The engagement delivered a working first prototype of the NACHA-to-EDI 820 conversion pipeline, establishing a proven path from partner file intake to compliant EDI output.
- By diagnosing and documenting the DX 10.2HF2 SSL workaround, the team protected the fixed migration deadline and left the bank with a reusable fix for future deployments, plus a foundation it can extend into a file-conversion service for its own customers.
Solving something similar?
We will walk your current data landscape and show you what a governed customer view would take.
