Get FI Data XML

​

Overview

​

Use Cases

• Legacy system integrations: Enterprise applications built on older technology stacks that have established XML processing infrastructure and cannot easily adopt JSON parsing.
• XML-based ETL pipelines: Data warehouse and analytics systems that use XML as a standard interchange format for ingesting financial data from multiple sources.
• SOAP web service integrations: Applications that operate within SOAP-based architectures where XML is the native data format for all service communications.
• Regulatory reporting systems: Compliance and reporting platforms that require XML-formatted financial data to meet specific regulatory filing requirements.
• Financial data transformation workflows: Systems that apply XSLT transformations or XML schema validation as part of their data processing pipelines.

​

Authentication

​

HTTP Request

POST {{Base_URL}}/xml/getfidata

​

Request Parameters

​

Request Body Example

{
    "consentID": "3c92001e-57ea-4320-bbb8-66d524bfb435",
    "linkReferenceNumber": "2f0e8d74-2b5f-4a4e-856d-2b73bf8ff792"
}

​

Response Format

​

Success Response

​

Response Parameters

​

Response Example

<?xml version="1.0" encoding="UTF-8"?>
<Response>
    <ver>1.21.0</ver>
    <status>success</status>
    <data>
        <linkReferenceNumber>2f0e8d74-2b5f-4a4e-856d-2b73bf8ff792</linkReferenceNumber>
        <maskedAccountNumber>XXXXXXXX3900</maskedAccountNumber>
        <balance>101666.33</balance>
        <fipName>FinShareBankServer</fipName>
        <fipId>finsharebank</fipId>
        <fiType>DEPOSIT</fiType>
        <fiData>
            <transaction>
                <transactionTimestamp>2025-11-13T14:25:30.000Z</transactionTimestamp>
                <txnId>TXN123456789</txnId>
                <type>CREDIT</type>
                <amount>5000.00</amount>
                <balance>101666.33</balance>
                <mode>UPI</mode>
                <narration>UPI/SALARY CREDIT/REF123</narration>
                <reference>REF123</reference>
                <valueDate>2025-11-13</valueDate>
            </transaction>
            <transaction>
                <transactionTimestamp>2025-11-12T09:15:00.000Z</transactionTimestamp>
                <txnId>TXN123456788</txnId>
                <type>DEBIT</type>
                <amount>1500.00</amount>
                <balance>96666.33</balance>
                <mode>CARD</mode>
                <narration>POS Purchase - Retail Store</narration>
                <reference>CARD5678</reference>
                <valueDate>2025-11-12</valueDate>
            </transaction>
        </fiData>
    </data>
</Response>

​

Error Handling

​

Error Response Format

​

Common Error Codes

​

Error Response Example

<?xml version="1.0" encoding="UTF-8"?>
<Response>
    <ver>1.21.0</ver>
    <timestamp>2025-11-14T11:51:28.773Z</timestamp>
    <errorCode>InvalidLinkReference</errorCode>
    <errorMsg>Link Reference Number not associated with this consent.</errorMsg>
    <status>failure</status>
</Response>

​

Supported Account Types

• Current Account (DEPOSIT): Business or high-transaction-volume checking accounts with no balance restrictions.
• Savings Account (DEPOSIT): Personal deposit accounts that typically earn interest and have transaction limits.
• Fixed Deposit (TERM_DEPOSIT or TERM-DEPOSIT): Time-bound deposits with fixed interest rates and maturity dates.
• Recurring Deposit (RECURRING_DEPOSIT): Regular installment-based deposits that build savings over time with predefined contributions.

​

Usage Notes and Best Practices

​

XML Processing Considerations

• The response is a well-formed XML document that can be parsed using standard XML parsing libraries (DOM, SAX, or StAX parsers depending on your technology stack).
• Implement robust XML parsing with proper error handling for malformed XML, unexpected elements, or missing required fields.
• Consider using XML schema validation (XSD) if you need strict validation of the response structure against expected format specifications.
• For large transaction datasets, consider using streaming XML parsers (SAX or StAX) rather than loading the entire document into memory (DOM) to improve performance and reduce memory consumption.

​

Character Encoding and Special Characters

• The XML response uses UTF-8 encoding to support international characters in narration fields, account holder names, and other text content.
• Ensure your XML parser is configured to handle UTF-8 encoding correctly to prevent character corruption issues.
• Transaction narration fields may contain special characters (ampersands, quotes, angle brackets) that will be properly XML-escaped in the response; your parser should handle these automatically.

​

Consent and Account Linking Prerequisites

• Before calling this API, ensure that you have received a DATA_READY webhook notification for the specific linkReferenceNumber you want to query.
• The linkReferenceNumber is generated and provided by the Account Aggregator when a user successfully links an account during the consent approval flow.
• Store linkReferenceNumber values from webhook notifications in your database, indexed by consent ID, to enable efficient data retrieval.

​

Data Freshness and Timing

• The data returned reflects the information available at the time of the last successful data fetch from the Financial Information Provider (FIP).
• For PERIODIC consents, data is refreshed according to the fetch frequency configured in your consent template (e.g., daily, weekly).
• For ONETIME consents, data represents a snapshot at the time of consent approval and will not update automatically.
• Transaction timestamps indicate when transactions were processed by the FIP, which may be different from when the data was fetched and made available through this API.

​

Transaction Data Characteristics

• Transactions within the <fiData> element are typically ordered reverse chronologically (most recent transactions first), though ordering should be verified by examining transactionTimestamp values.
• The <balance> field within each transaction element shows the running balance after that specific transaction, enabling you to verify transaction sequences and detect any missing transactions.
• The <mode> field provides standardized payment method codes, but the specific codes available depend on what the FIP includes in their data; not all modes may be present for all transactions.
• The <narration> field contains unstructured text that varies significantly in format and content across different banks; implement pattern matching or natural language processing to extract meaningful information like merchant names or transaction purposes.

​

XML Response Size and Performance

• XML format typically produces larger payloads compared to equivalent JSON data due to verbose tag naming and closing tags, resulting in higher bandwidth usage and potentially slower network transfer times.
• Consider implementing response compression (gzip) at the HTTP layer to reduce bandwidth consumption, especially for accounts with extensive transaction histories.
• For very large transaction sets, consider implementing pagination logic at the application level by making multiple API calls with date ranges, though this may require coordination with FinPro support to configure date-filtered queries.

​

XML to Database Mapping

• Design your database schema to accommodate the hierarchical structure of XML data, particularly the repeating <transaction> elements within <fiData>.
• Implement transformation logic to flatten XML hierarchy into relational database tables, maintaining foreign key relationships between account-level data and transaction records.
• Consider storing the raw XML response in addition to parsed data to preserve the original format for auditing, compliance, or reprocessing needs.

​

Error Handling and Validation

• Implement XML schema validation against the expected response structure to catch format changes or unexpected data anomalies early in your processing pipeline.
• Parse error responses separately from success responses, checking the <status> element value before attempting to extract data elements.
• Log both successful and failed API responses with full XML content (sanitizing sensitive data) to facilitate debugging and support escalation.

​

Comparison with JSON Endpoint

• Performance: JSON endpoints typically have slightly better performance due to smaller payload sizes and more efficient parsing in modern programming languages.
• Compatibility: XML endpoints provide better compatibility with legacy systems and enterprise integration platforms that have mature XML processing capabilities.
• Development effort: JSON is generally easier to work with in modern application development, with simpler parsing and better integration with contemporary frameworks.
• Choose XML when: Your integration architecture specifically requires XML format, you have existing XML processing infrastructure, or regulatory requirements mandate XML data formats.
• Choose JSON when: You’re building new integrations, performance is critical, or your development stack has strong JSON support.

​

Compliance and Data Security

• Financial transaction data contains sensitive personal information; ensure compliance with data protection regulations (GDPR, DPDPA, etc.) in how you store and process XML responses.
• Implement data retention policies aligned with regulatory requirements and securely delete XML files when they are no longer needed or consent is revoked.
• Use encrypted storage for cached XML data and ensure secure transmission (TLS 1.2+) for all API communications.
• Sanitize XML content before logging to prevent exposure of sensitive account numbers, transaction details, or personal information in log files.

​

Related Endpoints

• Get FI Data: Provides the same transaction data in JSON format, recommended for most modern integrations due to better performance and easier parsing.
• Get All FI Data: Retrieves transaction data for all accounts linked to a consent in a single API call, available in JSON format.
• Get All Latest Data: Fetches only incremental updates for PERIODIC consents, optimizing bandwidth and processing for regularly updated data (JSON format).
• Get FI Balance: Retrieves only the current balance for an account without transaction details, ideal for dashboard displays and quick balance checks (JSON format).