Money Movement

API - V 2.5

Download Postman collection

Introduction

Facilitating the transfer of funds between accounts is one of the most common and fundamental functions of a financial institution (FI). Customers rely heavily on the ability to manage their finances by transferring money to pay bills and moving funds between their own multiple accounts or to those of family members.

Money Movement services provide the capabilities to perform transfers between a customer’s accounts, as well as the creation and management of external recipients (other account holders at the same financial institution) who can also receive transfers.

Two APIs support these tasks:

The Recipient Service provides method for creating and retrieving these recipient records:

Create Recipient
Validate Recipient
Update Recipient
Delete Recipient
Retrieve a list of Recipients
Retrieve a single Recipient

The Transfers API makes this money movement possible by offering a set of basic services used to to the following:

Perform one-time transfers
Schedule future transfers
Execute scheduled transfers

These services can be used within accounts owned by one customer (including payments to IRA and loan accounts) as well as between different customer accounts.

Value

The Recipient Service APIs enable customers to:

Move funds between trusted members of one’s family or business directly (account-to-account)

They enable the financial institution to:

Enhance customer satisfaction
Increase likelihood of gaining business from entire families and commercial entities

They enable developers to:

Manage recipient records all in one convenient service

The Transfers API enables customers to:

Move money between accounts accounts
Meet savings goals, ensuring sufficient funds for bill payment
Set up automated transfers

It enables financial institutions to:

Provide transfer capabilities to satisfies customer needs
Improve reputation and increase potential for customer retention

It enables developers to:

Provide a “one-stop shop” for all types of transfer capabilities (from one-time transfers across customer accounts to intro-FI and cross-account money movement through loan payments and transfer scheduling, etc.)

What is Supported

While the Recipients service technical documentation in the API Specs section describes all the endpoints (or ways to call the API with different parameters to execute different actions), the following provides a simplified list of use cases for the API:

Create Recipient - Before a transfer can take place, a recipient record must be created and stored:
- Identify the recipient as a valid customer of the FI, with the proper account for transfer
- Identify the account to receive transfers
- Identify the recipient’s email address and display nickname
- Input the recipient’s passcode (needed to validate transfer execution)
- Validate the recipient (calls the Validate Recipient API)
Validate Recipient - Before a recipient record can be saved, the system must validate the data entered for the recipient record:
- Send the customer ID of the recipient
- Send the recipient’s account number to receive transfers
- Send the recipient’s account type
- Send the recipient’s passcode
Update Recipient - When changes are needed for an existing recipient record:
- Update the recipient account
- Update the recipient email address and display nickname
- Re-validate the recipient record (calls the Validate Recipient API)
Retrieve a List of Recipients - After one or more recipient records are created, the list can be retrieved:
- Commonly used in the context of creating a list of recipients to be selected during a transfer
- Retrieves all recipient records created by a given customer, along with their associated data
Retrieve a single Recipient - To view a recipient record or to select it for use in a transfer:
- Commonly used when the customer selects a recipient from the list called up using the previous API
- All data associated with a single recipient is returned
- Recipient data is then sent to a transfer operation

NOTE: Intra-FI transfer capability works differently in various types of FI host interfaces and hosts (called “providers”). Each interface and host that supports Intra-FI transfers requires validation methods specific to their provider type to create recipient records and execute transfers. The Recipients service provides three different provider validation methods:

GENERIC - The majority of interfaces/hosts support this method.
NON-GENERIC - A minority of interfaces/hosts support this method.
PHOENIX - A small number of interfaces/hosts support this method.

These three methods cover approximately 80% of all FI systems that support intra-FI Transfers. When creating and validating recipient records, the system must use the proper provider type. If you are working with an FI that does not support one of these three types, then a new one must be designed and implemented in the Recipients service.

While the technical documentation in the API Specs section describes the endpoints (or ways to call the API with different parameters to execute different actions), the following provides a simplified list of use cases for Transfers:

Execute One-Time Transfers -
Based on user input and configurations, there are several types of transfers that serve different purposes:
- Standard: A transfer of funds from one user account to another (checking to savings and vice-versa)
- Cross-Member: A transfer between a user account and one shared with another, usually a family member
- Cross-TIN: A transfer between two business entities, both owned by a customer
- IRA Contribution: A transfer from a cash account to an IRA account held by an FI customer
- Loan Payment: A transfer from a cash account to pay down or pay off a loan held by the customer with the FI
- Intra FI: A transfer from the account of one customer to another within the same FI, the recipient having been identified and authorized beforehand
Execute Test Transfers for all the above transfer types:
- It’s a common practice to perform a test transfer (usually of one cent in value) of the same type between the same accounts.
  - The test transfer returns information relative to Reg D requirements, informing the user of the number of transfers and limits within the month.
  - Based on this information, a fee may be charged for the transfer. The amount will be returned in the response.
  - This information can be displayed to the user before they commit to the transfer.
- Each of the transfer types named above can be preceded by a test transfer of the same type.
Schedule Future Transfers for all the above transfer types:
- A single or recurring transfer can be defined and scheduled for future dates.
- All transfer types named above, for Retail and Business banking, can be scheduled.
- The length of time a scheduled transfer will remain active is referred to as “Life Type”. The possible Life Type values are:
  - ENDDATE - The schedule will stop executing when the supplied end date is reached.
  - NUMBEROFEXECUTIONS - The schedule will stop executing once the specified number of executions has been reached.
  - NOENDDATE - The schedule will execute until it is cancelled.
- Scheduled frequency is defined as:
  - ONETIME
  - DAILY
  - WEEKLY
  - BIWEEKLY
  - TWICEMONTHLY
  - MONTHLY
  - EVERY4WEEKS
  - EVERY8WEEKS
  - QUARTERLY
  - SEMIANNUALLY
  - ANNUALLY
- With any WEEKLY schedule, the Day of the Week (Mon, Tue, Wed…) can be specified.
- With any MONTHLY schedule, the Day of the Month (1,2,3…) can be specified.
Retrieve one or a list of Scheduled Transfers
- The customer can review all scheduled transfers and their details, and they can ensure all needed transfers are properly scheduled.
Delete Scheduled Transfers
- Once a schedule is no longer needed, it can be deleted. The transfer will no longer be executed.

Additional Product Information

Sample Responses

Retrieve a list of recipients

Http Status : 200 OK

{"Recipients": [
{
"id": "0139e99d544f4ec39e1681cbf8c682e8",
"institutionId": "02122",
"memberNumber": "RECIPIENT09",
"institutionCustomerId": "a1fb5e6d2bf1491a9e22f59f7238d00a",
"accountNumber": "1234569170",
"accountType": "UNKNOWN",
"passCode": "FER",
"email": "x@example.com",
"nickName": "Ch ! @ # $ % ^ & * ( ) - . ; : ,"},
{``"id": "ba1a4209d04d4aa689ec8e0f57ecf034",
"institutionId": "02122",
"memberNumber": "RECIPIENT05",
"institutionCustomerId": "a1fb5e6d2bf1491a9e22f59f7238d00a",
"accountNumber": "1234569130",
"accountType": "CHECKING",
"passCode": "A",
"email": "other.email-with-hyphen@example.com",
"nickName": "One letter passcode"},
]
}

Retrieve a single recipient