AT A GLANCE
IFP Gateway is a webservice server software to receive XBRL financial reports via the IFP standard within the scope of the DiFin project – Digitaler Fananzbericht.
Valid financial reports are passed through via spooling or webservice to a subsequent credit risk management system – e.g. reportfactory© analytics. Financial reports which do not fulfil the specified conditions with regard to security and content are rejected automatically.
TOP 5 FEATURES
Declaration of conformity/
Every IFP Gateway release is checked against the official test server. On this basis the DiFin office accepted the declaration of conformity for the IFP Gateway.
Certified XBRL validation/
Every submitted XBRL report is validated with our certified XBRL processor ABRA TE.
Automatic configuration of new taxonomy versions/
New taxonomy versions are just provided as a Taxonomy Packages (ZIP archive) to the server. IFP Gateway automatically detects them and configures them to accept reports for the new taxonomy versions.
Integrated certificate verification/automatic CRL update/
Integrated certificate verification/
automatic CRL update/
The signature of every incoming message is checked and the used certificate is verified and checked against the certificate revocation list (CRL).
Spooling and webservice mode/
IFP Gateway hast two operating modes. With webservice mode incoming reports are sent via REST API to the susequent credit risk system. With spooling mode incoming messages are stored in the file system. Other systems in the processing pipeline can fetch them from there.
CERTIFIED XBRL VALIDATION ENGINE
We are using the certified XBRL engine of our own ABRA XBRL processor to validate the incoming financial reports. The engine is integrated in various products, both ours and our customers’, and is proven to process huge amounts of data.
Receipt of incoming filing/
The incoming filing is handled according to IFP and the processing within IFP Gateway is started.
Generate financial report ID (JA-ID)/
For every incoming financial report a unique ID (JA-ID) is generated. It serves the purpose to identify the financial report within the subsequent systems.
Incoming message handling/
- Message decryption
- Digital signature validation
The digital signature is checked for integrity and the certificate chain is checked for the correct origin (root).
- XBRL financial report extraction
The embedded XBRL report is extracted from the payload and provided for the next processing steps.
- PDF attachment extraction (one or more)
The payload can contain multiply PDF documents. Those are extracted and kept ready to transfer to the subsequent systems.
- Complementary webservice data extraction
The functional data fields outside of the XBRL report are extracted and converted to a separate XBRL report kept ready to transfer to the subsequent systems.
Proof of entitlement/
The filer’s address is checked against a configurable black or white list. Based on the result the processing is continued or the filing is rejected.
XBRL financial report validation/
- Referenced taxonomy check
The allowed taxonomies are configured in IFP Gateway. It utilises Taxonomy Packages standard which means that configuration is done by copying the taxonomy archive into a directory.
- XBRL 2.1 validation
The XBRL financial report is validated to the XBRL 2.1 rules.
- XBRL Dimensions 1.0 validation
The XBRL financial report is validated to the XBRL Dimensions 1.0 rules.
- XBRL Formula 1.0 validation
XBRL Formula 1.0 validation can be switched on via configuration. These validation capabilities are planned for future DiFin versions but IFP Gateway is ready for it as of today.
Transfer to credit risk management system or reportfactory© analytics/
All received data together with the validation report are stored in the file system.
All received data together with the unique ID and the validation report are sent via REST/JSON to the credit risk management system.
Send filing response/
- Embed validation report
If the financial report is rejected the validation report is embedded into the response message.
- Digital signature
The response message is signed with a digital signature. The certificate can be configured.
- Java 2 Standard Edition Runtime Environment (JRE), release version 8.0 or higher
- Java EE container with servlet version 3.0
- Minimum 4 GB RAM and 600 MB disk space
- The required RAM depends on the number of configured taxonomies
- SSL certificate for https encryption
- Domain or subdomain fort he webservice address
- IFP – certificate