Account Reconciliation for Card Issuing Sponsorship Programs
This guide provides a detailed overview of the account reconciliation process for card issuing sponsorship program, designed to help fintech companies ensure accurate financial management. As a fintech company looking to issue cards, understanding the reconciliation process is crucial. Let's walk through the steps and requirements.
Understanding Account Reconciliation
One of the key steps in this journey is ensuring that all financial transactions are accurately recorded and reconciled. Account reconciliation is the process of comparing two sets of records to identify any discrepancies, ensuring that account balances are correct at the end of a particular accounting period.
For example, if a transaction is recorded in your processing platform, but doesn’t appear in your bank statements, reconciliation helps identify and resolve such issues.
Initial Reconciliation Setup
This section of the guide outlines the key steps to set up reconciliation for card issuing sponsorship program, focusing on defining fund flows, account structures, data formats required for accurate reconciliation.
Steps in Reconciliation Setup include:
- Program Engagement & Overview
- Define Flow of Funds
- Set up Accounts
- Transaction Data Mapping Exercise
- Reconciliation File Specification
- Milestone and Testing Plan
- Approval and Launch
1. Program Engagement & Overview
Our Newline Client Success (NCS) team will conduct an onboarding session with your team, providing an overview of the reconciliation process. The session ensures alignment on program goals, transaction volume expectations, and map out the funds flow.
2. Define Flow of Funds
Newline will collaborate with you to map the flow of funds, including how money moves between customer payments, reserve accounts, and settlements. We will also work with you to determine the necessary account structures to manage operational efficiency, such as separate accounts for reserves and settlements. This step is crucial to ensure that all financial transactions are accurately tracked and reconciled.
3. Set up Accounts
During this step, we will assess whether multiple accounts are required for better fund management and reporting. We will work with you to open and configure accounts based on program needs.
4. Transaction Data Mapping Exercise
During this step we will review how your platform structures transaction data (e.g. transaction IDs, timestamps, and metadata.) We will discuss key reconciliation details such as transaction codes, unique IDs, and timestamps to ensure seamless integration.
5. Reconciliation File Specification
You will receive the following file templates for submitting your program’s transaction and balance data.
- EOD Balance File: Provides a snapshot of total balances at the end of each day. This file is used for daily reconciliation to ensure all transactions are accounted for.
- Transaction Detail File: Contained detailed list of all transaction activities within a given period, including fields like transaction_id, timestamp, and amount.
The End-of-Day (EOD) Balance Data File Structure
| Name | Size | Description | Example |
|---|---|---|---|
| Company | 5 | This is a hardcoded abbreviation of the client's company name in our system. | ABCDE |
| Source ID | 10 | The Source ID uniquely identifies the origin of the file within the system, specifying its source location. | BALANCE |
| Bank No. | 3 | Identifies the bank number associated with the client's account. Right-Justified, zero fill | 001 |
| Account No. | 15 | Specifies the IDDA account number associated with the client/program. This is specific to the client and or program. IDDA stands for Internal Direct Deposit Account (Bank Owned). Right-Justified, zero fill | 000000000123456 |
| Cost Center | 5 | Newline will provides clients with a cost center number that Identifies the cost center associated with a transaction. Right-Justified, zero fill | 00001 |
| Amount | 20 | Represents end-of-day total customer balance. Right-Justified, zero fill – Explicit decimals (2 decimal positions) | 000000000000012345.67 |
| DCIP | 6 | Debit or Credit (case sensitive). This should represent the total position of the portfolio, which we would expect to be "Credit". | Credit |
| Date Posted | 8 | Posted Date represents the program cutoff date which should also align with the money movement. Format YYYYMMDD | 20241213 |
The Transaction Detail File Data File Structure
| Name | Size | Description | Example |
|---|---|---|---|
| Company | 5 | Hardcoded abbreviated company name. | ABCDE |
| Source ID | 10 | The Source ID uniquely identifies the origin of the file within the system, specifying its source location. | DETAIL |
| Bank No. | 3 | Identifies the bank number Right-Justified, zero fill | 001 |
| Account No. | 15 | Specifies the account number. Right-Justified, zero fill | 000000000123456 |
| Cost Center | 5 | Identifies the cost center associated with the transaction Right-Justified, zero fill | 00001 |
| Class | 5 | Classifies the type of transaction. | 00140 |
| Amount | 20 | Indicates the transaction amount. Right-Justified, zero fill – Explicit decimals (2 decimal positions) | 000000000000012345.67 |
| DCIP | 6 | Debit or Credit (case sensitive) | Debit |
| Date Posted | 8 | The date the transaction was posted. YYYYMMDD | 20241213 |
| Date Available | 8 | The date the transaction is available. YYYYMMDD | 20241213 |
| Description Field 1 | 150 | Provides the card number associated with the transaction. | 1234567890123456 |
| Description Field 2 | 50 | Provides the Acquirer Reference Number (ARN) | ARN1234567890 |
| Tran Code | 10 | Indicates the transaction code. | TRN1234567 |
Note:
These are the minimum file requirements for each file. Additional fields may be required, depending on the specifics of the program.
6. Milestone and Testing Plan
To ensure the reconciliation setup functions seamlessly, we follow a structured testing approach. This phase verifies that the reconciliation file meet specifications, data flows are accurate, and financial transactions are correctly processed. Testing includes both User Acceptance Testing (UAT) and Production Testing.
UAT Testing
User Acceptance Testing (UAT) is a validation phase where your team provides test files in the agreed formats to simulate real-world scenarios. The goal of UAT is to confirm that the reconciliation process works as intended before moving to production.
What’s happening during this Phase?
- Submit test files in the specified formats (EOD Balance and Transaction Detail) for validation by Newline.
- Files are reviewed to ensure accuracy and compliance with reconciliation requirements.
Production Testing
Production Testing is the final validation phase conducted in the live environment with minimal activity to ensure that actual money movement, data flow, and reconciliation processes function as expected. This typically involves small-dollar transactions to confirm that all systems are integrated correctly, and any discrepancies can be identified and resolved before scaling up.
What’s happening during this Phase?
- Perform small-dollar transactions in the production environment to verify real-world money movement.
- Confirm reconciliation file submissions are accurate and operational.
7. Approval and Launch
- After successful UAT and production testing, we will finalize the reconciliation setup.
- If any discrepancies or issues occur post-launch, our team will assist in troubleshooting and resolution to maintain a smooth reconciliation process.
Updated 21 days ago