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 .
Below changes are done in request body AccDiscoveryRequest
model.
fiTypes
from common model
FITypes
Related to changes in POST /Consent
API.
{
fiTypes:
$ref: '#/definitions/FITypes'
}
TERM_DEPOSIT
in FITypes
model.Related to changes in POST /Consent
API.
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
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:
{
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.
}
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.
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:
POST /Accounts/discover
POST/Consent
from Experimental AA APIGET /Consent/{id}
from Experimental AA API{
fiTypes:
$ref: '#/definitions/FITypes'
}
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:
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
Frequency
field.Frequency
field in
SignedConsentDetail
model which is referred in the ConsentArtefact
model. FIU needs to implement business logic as per the updated description.POST/Consent
from Experimental AA API{
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
}
Below changes are done in the request body i.e. Keymaterial
model which is referred in the
FIRequest
model.
params
and
Nonce
field.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.{
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'
}
Below changes are done in the response body i.e. Keymaterial
Model and encryptedFI
field which is referred in the
FIFetchResponse
model.
params
and
Nonce
fieldRelated to change in POST /FI/Request
API.
{
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'
}
encryptedFI
fieldencryptedFI
field was incorrectly considered as file data type
instead of string after compilation.encryptedFI
field of
FIFetchResponse
model. GET /FI/Fetch/{sessionId}
from Experimental AA API{
encryptedFI:
type: string
format: binary //Removed
description: Contains the encrypted financial information based on the
key material defined corresponding to the user's Account.
}
format: byte
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.format: byte
{
format: byte // Removed
}