DXC Hogan Accounts System API

About Hogan Accounts System API

Hogan APIs are the system-level APIs used to interact with Hogan business applications like CIS (Customer Information System), IDS (Integrated Deposits System), FSS (Financial Support System), ILP (Integrated Loans Processing), and CAMS II (Cards and Merchant System). This system of record APIs exposes Hogan's business functions to client applications via IBM z/OS Connect EE which provides JSON message format based RESTful API access to z/OS applications like Hogan.

z/OS Connect EE server components are installed on the mainframe and expose mainframe functions as web-based RESTful APIs which can be accessed over the web using the HTTP protocol. Because of the distinctive behavior of Hogan, z/OS Connect EE cannot work out of the box with it. DXC Technology built a Hogan interface by extending the Hogan Umbrella engine to provide an infrastructure for simplification of the API build process inside the Hogan environment as well as a conduit for passage of data inside and outside the Hogan environment. Client applications are expected to send and receive data in JSON-based message format which is converted to Hogan understandable data format by a combination of components running inside z/OS Connect EE as well as inside Hogan core. DXC provides 81 CIS, IDS, and FSS APIs bundled as separate families along with the infrastructure components. However, the interface infrastructure is meant to build APIs in the bank’s customized environment.

Following general business functions are supported by Hogan APIs:

-Customer creation and maintenance

-Account (deposits, loans, Cards) creation and maintenance

-Address creation and maintenance

-Relationship management – Customer to account, customer to address, etc.

-Transaction Posting

-Transaction listing, Statements

-Funds Transfer

-Create manage Direct Debit

-Account Sweep

-Restraints and hard holds

-Account Payoff

-Branch and currency management

Prerequisites

To use these APIs, you should be familiar with:

• Web-based RESTful APIs which provide standardized JSON input & output payloads based on OpenAPI specification format
• Mule runtime engine
• Anypoint PlatformTM Connectors and Anypoint PlatformTM Studio
• Mule runtime engine concepts
• Elements in a Mule flow and Global Elements

API configuration

Hogan APIs are deployed on the z/OS Connect EE server on the mainframe platform. These are invoked via the web-based URI along with the appropriate HTTP verb. Invocation of API can be done by providing the following header parameters:

Expected Flow

The Hogan APIs allow client applications to invoke Hogan business functions using web-based HTTP invocation including header parameters, authorization parameters, HTTP verb, URI path & query parameters, and JSON request payload. The flow of API invocation passes through the z/OS Connect EE and executes the respective runtime components based on the URI path. These components in turn pass the control into the Hogan API Umbrella interface components defined for an API. These APIs invoke Hogan business application components to Inquire/Add/Modify/Delete objects inside the Hogan application and the outcome of the execution is sent back to the client application via the z/OS Connect EE server.

Hogan APIs response provides HTTP 400, 500, 405, and 503 as fault codes. HTTP 200 signifies a successful execution of an API. Further status of an API execution in the case of HTTP 200 is shown as part of every API JSON response structure. An example of a standard status message is shown below.

"xStatus": {

"applicationCd": 0,

"statusCd": 64120,

"statusMessage": "ACCOUNT ADDED TO FILE",

"severity": "E"

}

Use cases

Hogan Accounts APIs are the system-level APIs used to invoke the following Hogan IDS (Integrated Deposits System) business functions.

1. Create Checking Account

HTTP Verb: POST

Purpose: Create a new Checking (DDA) account.

Request Payload: All ASET fields + DDMU Field 1, Field 11, and Field 13.

Response Payload: All ASET fields + DDMU Field 1, Field 11, and Field 13.

2. Create Savings Account

HTTP Verb: POST

Purpose: Create a new Saving (RSV) account.

Request Payload: All ASET fields + TDMU Field 1, Field 11, and Field 13.

Response Payload: All ASET fields + TDMU Field 1, Field 11, and Field 13.

3. Create Certificate of Deposit Account

HTTP Verb: POST

Purpose: Create a new Certificate of Deposit (CDA) account.

Request Payload: All ASET fields + TDMU Field 1, Field 11, and Field 13.

Response Payload: All ASET fields + TDMU Field 1, Field 11, and Field 13.

4. Create Individual Retirement Account

HTTP Verb: POST

Purpose: Create a new Retirement (REA) account.

Request Payload: All ASET fields + TDMU Field 1, Field 11, and Field 13.

Response Payload: All ASET fields + TDMU Field 1, Field 11, and Field 13.

5. Get Deposit Account Transaction List

HTTP Verb: GET

Purpose: Fetch account transactions for all kinds of checking and savings accounts (DDA, RSV, REA, CDA). The transactions can be filtered based on any or all of (1) begin and end Effective Date, (2) Begin and end amount, (3) begin and end posting date, (4) begin and end check number, and (5) transaction type (credit or debit).

Request Payload: THMU fields to provide the filter criteria. Request payload also contains offset and limit fields to assist in the pagination of response data.

Response Payload: THFI and SDET fields are provided as responses for transactions fetched from Hogan IDS applications. Maximum 190 transaction occurrences are supported.

6. Post Deposit Account Transactions

HTTP Verb: POST

Purpose: Post monetary deposit/withdrawal/reversal to Checking or Savings Account; transfer funds to/from Checking/Savings Accounts. All DDA and TDA product codes are supported.

Request Payload: Key fields (COID, Product Code, and Account Number) and other mandatory fields like transaction code, transaction amount, and GLI source.

Response Payload: Posting information, general transaction information, transfer information, paid into overdraft information, override information (TDA only), and addendum information fields are part of the payload.

7. Update Checking Account

HTTP Verb: PATCH

Purpose: Perform checking account maintenance.

Request Payload: Primary account information and to be updated information from various DDMU fields.

Response Payload: Primary account information and updated information from various DDMU fields.

8. Update Saving Account

HTTP Verb: PATCH

Purpose: Perform saving account maintenance.

Request Payload: Primary account information and to be updated information from various TDMU fields.

Response Payload: Primary account information and updated information from various TDMU fields.

Additional resources

• Swagger specification documents of each of the Accounts API