1. File Interface Specification Guide
  2. File Format

2 File Format

This topic provides information about the principles of file based communication between Oracle Banking Collections and any product processor.

  1. File Format: The acceptable incoming and outgoing file format for the data file is CSV (Comma-Separated Values) file.
  2. Each product processor must send data in different CSV file to Oracle Banking Collections.
  3. File Naming Convention:

    New Accounts: For the new accounts coming into Oracle Banking Collections, there will be a single file which contains Account as parent and then its related data as provided in chapter File Interface. The data file should be named as per convention: OBCR-FEED-INBOUND_OBCR_*.csv.

    Existing Records: For the updates of existing records coming into Oracle Banking Collections, there will be individual files for each entity. The data file should be named as per convention: OBCR-FEED-ENTITY_NAME_OBCR_*.csv. The ENTITY_NAME in this file name should be as given in table below. For example, if the updates are for Account Details entity, the file name should be OBCR-FEED-ACCOUNT_OBCR_*.csv.

    Table 2-1 Entity Name for Update Records

    Entity Entity_Name
    Account Details ACCOUNT
    Payment Details PAYMENT
    Account Arrears Details ACCOUNT-ARREARS
    Account Bill Details ACCOUNT-BILL-DTLS
    Account Repayment Schedule Details ACCOUNT-REPAY-SCH
    Account Party Relationship Details ACCOUNT-PARTY
    Party Details PARTY
    Party Name Details PARTY-NAME
    Party Address Details PARTY-ADDRESS
    Party Contact Details PARTY-CONTACT
    Party Identity Details PARTY-IDENTITY
    Party Employment Details PARTY-EMPLOYMENT
    Risk Indicator Details RISK-INDICATOR
    Collateral Linkage Details COLLATERAL-LINKAGE
    Collateral Details COLLATERAL
    Collateral Owner Details COLLATERAL-OWNER
    Collateral Charge Details COLLATERAL-CHARGE
    Insurance Details INSURANCE
  4. Content of the File
    New Accounts: For the new account coming into Oracle Banking Collections:
    • Each file should have a header at the top mentioning HEADER|<Product Processor Code>.
    • All records must be in sequence of parent child format. Account Data must be parent record, succeeded by other child data.
    • In case of account with multiple parties, details of each party should be sent together in below sequence only.
    • Some entities are required to be mandatory sent with data for new records.
    • For each record, data should start with specific tags and the sequence as mentioned in the table below:

    Table 2-2 Tags and Sequence for Entity Name for Create Record

    Sequence Entity Tag Required/Optional
    1 Account Details ACCT Required
    2 Account Arrears Details ARRS Optional
    3 Account Bill Details BILL Optional
    4 Account Repayment Schedule Details RSCH Optional
    5 Payment Details PYMT Optional
    6 Account Party Relationship Details APRL Required
    7 Party Details PARTY Required
    8 Party Name Details NAME Required
    9 Party Address Details ADDR Required
    10 Party Contact Details CONT Required
    11 Party Identity Details IDNT Optional
    12 Party Employment Details EMPT Optional
    13 Risk Indicator Details RIND Optional
    14 Collateral Linkage Details CLINK Optional
    15 Collateral Details COLL Required only if Linkage is present
    16 Collateral Owner Details COWNR Optional
    17 Collateral Charge Details CHARGE Optional
    18 Insurance Details INSU Optional
    Existing Records: For the updates of existing records coming into Oracle Banking Collections:
    • Each file should have a header at the top mentioning HEADER|<Product Processor Code>.
    • Each record should start with any of the below three indicators:
      • I: If the update is for new record to be inserted.
      • U: If the update is for update on the existing record.
      • D: If the update is for existing record to be deleted.
  5. Data in the file and its sequence should be as per the details provided in chapter File Interface. Each entity has its own template and the data should be in the same order of fields given in chapter File Interface.
  6. Each entity will have additional 50 User Defined Fields at the end. First 30 User Defined Fields are of the Data Type NUMBER with Maximum Length as 36. Next 10 User Defined Fields are of the Data Type VARCHAR with Maximum Length as 100. Last 10 User Defined Fields are of the Data Type DATE.
  7. Date and Time stamp formats: Each date field value in the data file should be of the format: YYYY-MM-DD. Each datetime/timestamp field value in the data file should be of the format: YYYY-MM-DD HH24:MI:SS. Where, MM - Month (Numeric) DD - Day (Numeric) YYYY - Year HH24 - Hours in 24-hour format MI - Minutes SS - Seconds.
  8. Pipe symbol ‘|’ should be used as a separator between two fields.
  9. Every field for the entity marked as Required in chapter File Interface must be provided in the data file. The fields marked as Optional should be given as a blank value in the data file, if the field value is null, so that the order of fields in the template is not disturbed. For example, template for an entity is: FIELD1|FIELD2|FIELD3. Where, FIELD1 and FIELD3 are Required fields, and FIELD2 is an Optional field. If the value for FIELD2 is null, then the record for the entity in the data file should be: VALUE1||VALUE3.
  10. If the file processing fails due to incorrect record or data issue in any record, the required correction should be done and only corrected record should be sent with the new file name.
  11. If any field of a record in the file is updated, then all other fields should also be provided for that entity record.