BankValidator architecture¶
BankValidator centers on a single façade class that wraps several generated ASMX SOAP clients and hides vendor-specific authentication, endpoint selection, and request sequencing from callers.
Responsibilities¶
- Centralize bank-validation and lookup operations behind
SAIF.clsValidateBank. - Create, authenticate, invoke, and dispose vendor SOAP proxies for ABA, ATM, and SSN operations.
- Convert selected vendor SOAP faults into stable caller outcomes for bank-lookup methods.
- Expose typed bank-detail data through the generated
InstitutionsDataSet.
Component boundaries¶
SAIF.clsValidateBank: Sole handwritten public entry point; owns credentials, endpoint URLs, retry settings, and all call orchestration.ABAService.ABAService: Generated SOAP client used for ABA validation, ABA verification, company lookup, and bank-detail retrieval.ABAExpress.ABAService: Generated SOAP client included in the project and disposed byclsValidateBank, but not invoked by any public method.ATMService.ATMService: Generated SOAP client used for ATM participation checks, status lookup, and status-code translation.OFACService.OFACService: Generated SOAP client included in the project and disposed byclsValidateBank, but not invoked by any public method.SSNKeyService.SSNKeyService: Generated SOAP client used for SSN validation.SAIF.Institutions: Auto-generated typed DataSet schema for bank-detail payloads returned byGetBankFullDS.
Interaction model¶
- Callers construct
clsValidateBankwith company ID, user ID, password, and an optional retry limit. - Each public operation selects one vendor service, performs a logon, issues one or more vendor calls, and then logs off.
- Service URLs are initialized to Lyons/CBIZ endpoints and can be overridden through public properties before use.
- Bank-detail methods catch
SoapExceptionand substitute empty results; most other vendor failures surface asApplicationExceptionor service exceptions.
Architecture diagram¶
The following diagram shows the façade and its generated vendor service clients.
flowchart TD
Caller[Calling application] --> Facade[SAIF.clsValidateBank]
Facade --> ABA[ABAService.ABAService]
Facade --> ABAExpress[ABAExpress.ABAService]
Facade --> ATM[ATMService.ATMService]
Facade --> OFAC[OFACService.OFACService]
Facade --> SSN[SSNKeyService.SSNKeyService]
Facade --> Institutions[SAIF.Institutions]
ABA --> Vendor[Lyons/CBIZ SOAP endpoints]
ATM --> Vendor
SSN --> Vendor
Sequence diagram¶
The following diagram shows the standard logon-call-logoff sequence used by an ABA validation request.
sequenceDiagram
participant Caller
participant Facade as clsValidateBank
participant ABA as ABAService
Caller->>Facade: IsValidABANumber(routingNum)
Facade->>ABA: Logon(companyId, userId, password)
ABA-->>Facade: logonToken
Facade->>ABA: ValidateABA(logonToken, routingNum)
ABA-->>Facade: Boolean result
Facade->>ABA: Logoff(logonToken)
Facade-->>Caller: Boolean result
Design constraints¶
- The library has no dependency-injection seam or configuration-file binding for service endpoints; endpoint overrides are code-only property assignments.
- The retry counter is shared across logon helper methods through
m_LogonAttempts. - Each operation performs synchronous network calls and does not pool or reuse authenticated sessions across public method invocations.
GetBankFullDSdepends on XML returned by the ABA service and loads that payload into the generatedInstitutionsDataSet schema.
Related documentation¶
Sources¶
Legacy\BankValidator\clsValidateBank.vbLegacy\BankValidator\Institutions.Designer.vbLegacy\BankValidator\Institutions.xsdLegacy\BankValidator\SAIF.Legacy.BankValidator.vbprojLegacy\BankValidator\Web References\ABAExpress\Reference.vbLegacy\BankValidator\Web References\ABAService\Reference.vbLegacy\BankValidator\Web References\ATMService\Reference.vbLegacy\BankValidator\Web References\OFACService\Reference.vbLegacy\BankValidator\Web References\SSNKeyService\Reference.vb