ReBIT

Financial Information Provider (FIP) Change Log

It summarizes the changes in the FIP APIs requested by the AA ecosystem community.
You can send the suggestions/queries regarding FIP APIs changes by mailing us on aa-api@rebit.org.in .

Feb 23, 2021

Summary

1. POST /Accounts/discover

Below changes are done in request body AccDiscoveryRequest model.

1.1. Referred fiTypes from common model FITypes

Related to changes in POST /Consent API.

Summary of changes in YAML
{
fiTypes:
	$ref: '#/definitions/FITypes'
}

1.2. Added new enum value as TERM_DEPOSIT in FITypes model.

Related to changes in POST /Consent API.

Summary of changes in YAML
FITypes:
    type: array
    minItems: 1
    items:
      type: string
      description: List of financial information types.
      example: DEPOSIT
      enum:
        - DEPOSIT
        - TERM_DEPOSIT //Added
        - TERM-DEPOSIT
        - RECURRING_DEPOSIT
        - SIP
        - CP
        - GOVT_SECURITIES
        - EQUITIES
        - BONDS
        - DEBENTURES
        - MUTUAL_FUNDS
        - ETF
        - IDR
        - CIS
        - AIF
        - INSURANCE_POLICIES
        - NPS
        - INVIT
        - REIT
        - OTHER
  

1.3. Updated description of Identifiers field

Why was this change needed? The API spec does not explicitly mention how strong and week identifiers to be used while discovering the account.
What about the old fields? NA
Has any data changed? NA
What has changed in the API? Updated the description of Identifiers field in AccDiscoveryRequest to state that all the strong identifiers must be authenticated before account discovery happens. E.g. An OTP can be sent to user if he is discovering the account using mobile number.
Other APIs impacted due to this change:

Summary of changes in YAML
{
Identifiers:
type: array
	items:
		type: object
		description:
				A set of Identifiers required for discovering the accounts of a
				customer at the FIP. It is mandatory to send at least one STRONG
				category Identifier. All identifiers which are used primarily for
				 discovery  must be authenticated to ensure that they belong to
				 the user to prevent malicious activity.
}

2. POST /Consent

Below changes are done in the request body i.e. Consent Artefact Model and SignedConsentDetail Model which is decrypted value of signedConsent field in ConsentArtefact model.Also, the ConsentDetail model is renamed to SignedConsentDetail for better clarity.

2.1. Referred fiTypes from common model FITypes.

Why was this change needed? FIType enumeration values were defined multiple times causing inconsistency.
What about the old fields? NA
Has any data changed? NA
What has changed in the API? Declared a common model for FIType with enumeration values and referred it in all occurrences in API spec.
Other APIs impacted due to this change:

Summary of changes in YAML
{
fiTypes:
	$ref: '#/definitions/FITypes'
}

2.2. Added new enum value as TERM_DEPOSIT in FITypes model.

Why was this change needed? Term deposit FI type was defined inconsistently as TERM-DEPOSIT in FIP APIs. Hence a new enum value TERM_DEPOSIT is added to maintain consistency across AA and FIP APIs.
What about the old fields? NA
Has any data changed? NA
What has changed in the API? Added new enum value as TERM_DEPOSIT in FITypes model.
Other APIs impacted due to this change:

Summary of changes in YAML
FITypes:
  type: array
  minItems: 1
  items:
    type: string
    description: List of financial information types.
    example: DEPOSIT
    enum:
      - DEPOSIT
      - TERM_DEPOSIT //Added
      - TERM-DEPOSIT
      - RECURRING_DEPOSIT
      - SIP
      - CP
      - GOVT_SECURITIES
      - EQUITIES
      - BONDS
      - DEBENTURES
      - MUTUAL_FUNDS
      - ETF
      - IDR
      - CIS
      - AIF
      - INSURANCE_POLICIES
      - NPS
      - INVIT
      - REIT
      - OTHER

2.3. Updated description of Frequency field.

Why was this change needed? Currently there is no limit specified on the frequency of FI data fetch. Hence the maximum frequency is defined as 1 request per hour. Similaraly it will be 24 requests per day and so on.
What about the old fields? NA
Has any data changed? NA
What has changed in the API? Updated description of Frequency field in SignedConsentDetail model which is referred in the ConsentArtefact model. FIU needs to implement business logic as per the updated description.
Other APIs impacted due to this change:

Summary of changes in YAML
{
Frequency:
	description: Defines frequency of FI data fetch within the defined time unit. E.g. HOURLY,DAILY,MONTHLY,YEARLY.
The maximum frequency value that can be defined is 1 request per HOUR. Similaraly it will be 24 requests per DAY and so on. Frequency can not be set below 1 request per hour. type: object }

3. POST /FI/Request

Below changes are done in the request body i.e. Keymaterial model which is referred in the FIRequest model.

3.1. Updated description of params and Nonce field.

Why was this change needed? The exact cryptographic parameters to be used for end-to-end encryption are not mentioned explicitly in the API spec. This might cause interoperability issues.
What about the old fields? NA
Has any data changed? NA
What has changed in the API? Updated params field description in the KeyMaterial model with exact cryptographic parameters to be used as "cipher=AES/GCM/NoPadding;KeyPairGenerator=ECDH". Also, updated description of Nonce field to mention that Nonce should have a fixed length and added a reference on how Nonce should be formed.
Other APIs impacted due to this change:

Summary of changes in YAML
{
params:
	type: string
	xml:
	attribute: true
	description: 'Specifies the secure standard cryptographic primitives to perform
	end to end encryption. Use Key-Value pair separated by a semicolon. The value
	given for cryptographic primitives in example should be used for symmetric
	encryption(AES-256 bits, GCM-128 bits and No Padding) and key exchangeprotocol(ECDH).'
	example: 'cipher=AES/GCM/NoPadding;KeyPairGenerator=ECDH'
}

{
Nonce:
	type: string
	example: '29512b70-ca84-46b5-9471-63765599cf15'
	description: 'Nonce is a random string generated every time during the publishing of
	Ephemeral public key to ensure that old communications cannot be reused in replay
	attacks. Nonce should have a fixed length. Unlike random numbers, random strings do
	not require byte ordering. Hence session keys can be generated in a platform
	independent way. Ref: https://tools.ietf.org/html/rfc5116'
}

4. GET /FI/Fetch/{sessionId}

Below changes are done in the response body i.e. Keymaterial Model and encryptedFI field which is referred in the FIFetchResponse model.

4.1. Updated description of params and Nonce field

Related to change in POST /FI/Request API.

Summary of changes in YAML
{
params:
	type: string
	xml:
	attribute: true
	description: 'Specifies the secure standard cryptographic primitives to perform
	end to end encryption. Use Key-Value pair separated by a semicolon. The value
	given for cryptographic primitives in example should be used for symmetric
	encryption(AES-256 bits, GCM-128 bits and No Padding) and key exchangeprotocol(ECDH).'
	example: 'cipher=AES/GCM/NoPadding;KeyPairGenerator=ECDH'
}

{
Nonce:
	type: string
	example: '29512b70-ca84-46b5-9471-63765599cf15'
	description: 'Nonce is a random string generated every time during the publishing of
	Ephemeral public key to ensure that old communications cannot be reused in replay
	attacks.Nonce should have a fixed length. Unlike random numbers, random strings do
	not require byte ordering. Hence session keys can be generated in a platform
	independent way. Ref: https://tools.ietf.org/html/rfc5116'
}

4.2. Removed line format:binary from encryptedFI field

Why was this change needed? The encrypted content in encryptedFI field was incorrectly considered as file data type instead of string after compilation.
What about the old fields? NA
Has any data changed? NA
What has changed in the API? removed line format:binary from encryptedFI field of FIFetchResponse model.
Other APIs impacted due to this change:

Summary of changes in YAML
{
encryptedFI:
	type: string
	format: binary //Removed
	description: Contains the encrypted financial information based on the
                      key material defined corresponding to the user's Account.
}

5. Common changes

5.1. Removed line format: byte

Why was this change needed?
format:byte is specified for x-jws-signature header and signedConsent field. Hence the string will be considered as base64 encoded string. However the format is not correct as JWS signature contains multiple base64 encoded strings connected with "." (dot). This might cause issue while compiling.
What about the old fields? NA
Has any data changed? NA
What has changed in the API? Removed format: byte
APIs impacted due to this change:

Summary of changes in YAML
{
	format: byte // Removed
}