The new Belgian Security Act amended and postponed

The Belgian act of 11 July 2013 with regard to security rights on movable assets (the “Security Act”) is not yet in force. Implementing regulations were expected to organize the pledges register and to correct some inaccuracies and loopholes.

The Belgian Law of 25 December 2016 (the “Law”) amends the Security Act to ensure its effective implementation and postpone (once more) its entry into force. In an effort to harmonize the regime of security rights on movable assets, the Law also amends other regulations such as the Law of 15 December 2004 concerning financial collateral arrangements, the Registration Duties Code and the Law of 3 August 2012 relating to various provisions in order to facilitate the mobilization of receivables in the financial sector.

1.   Main changes to the Security Act

The Law provides for a number of substantial changes to the Security Act which can be summarized as follows:

  • The date of entry into force of the Security Act is postponed the latest to 1 January 2018 (Article 109 Security Act). This measure was necessary because the pledges register, which is the cornerstone of the new regime organized by the Security Act, is not yet effective. To the extent that the pledges register would become operational earlier, the Belgian Government has agreed to bring the Security Act in force before 1 January 2018.                        
  • The Law expressly clarifies that the pledgee benefits from a preferential right equivalent to the lien referred to in Article 12 of the Mortgage law (Article 6 Security Act).
  • Express confirmation is given that a pledge may be created on all movable assets, even if the latter qualify, for civil law purposes, as immovable assets as a result of their intended use (“immeubles par destination / onroerend door bestemming”) (Article 12 Security Act).
  • The possibility for the pledgee to give its pledge in pledge to his own creditor(s) with the consent of the pledgor (“réengagement / herverpanding”), which was no more possible, is reinserted in Article 19 of the Security Act.
  • It will not be possible to register pledges on receivables in the future pledges register (Article 20 Security Act). The Security Act provided for two different ways to ensure the enforceability of pledges on receivables, being (i) the registration in the future pledges register and (ii) the dispossession. Because the Security Act cannot lead to an increase of the required formalities (set out in Article 1690 of the Civil Code), the legislator has decided to suppress the possibility to register pledges on receivables in the pledges register. This change is regrettable. Indeed, the registration was only an option and, in addition, the fact that pledges receivables will not appear in the pledges register will limit the usefulness of such register as it will not list exhaustively all pledges created on the assets of a debtor.
  • The Security Act’s provisions relating to the pledges register (Article 26 of the Security Act) and the registration (Article 29 of the Security Act) have been amended to allow the optional registration of retention of title clauses on moveable assets which became immovable assets through incorporation (“immeubles par incorporation / onroerend door incorporatie”). Such a possibility was provided for in Article 71 of Title XVII of Book III of the Civil Code relating to the registration of retention of title clauses, but the latter had still to be implemented.
  • The information to be mentioned in the pledges register are clarified in Article 36 and 37 of the Security Act. We note in particular :
  1. with respect to the identity of the pledgee and the pledger: (i) in case of a natural person, mention of the name, first surname or two first surnames, country, postal code and commune of principal residence and, if available, enterprise number; in the absence of enterprise number, National Registry number and date of birth; (ii) in case of a legal person, mention of the name, legal form, country, postal code and commune of registered office and, if any, its enterprise number.
  2. the assignments of the registration of pledges (or of a retention of title clauses) and the assignment of the rank relating to a registered pledge will have to be registered (which will trigger the payment of fees).
  • The pledgor should obtain the pledgee’s consent for any withdrawal or change to the data registered in the pledges register. The possibility for the pledgor to contact the Mortgage Service to correct an error appearing in the pledges register has been withdrawn. Any disagreements between pledgor and pledgee relating to erroneous data will have to be brought before the courts.
  • The full access by the public to the pledges register is the cornerstone of the new regulation (Art. 40 Security Act). A similar system of publicity already exists in respect of rights in rem on immovable assets and pledges on business assets though the Mortgage Register (« Registre des Hypothèques/Hypotheekregister »). The Belgian Commission for Protection of Privacy has advised limiting the access to the pledges register to persons with a legitimate interest. In the former version of the Security Act, such an access was therefore exclusively granted to the pledgors, the pledgees and certain categories of persons or institutions to be listed in a Royal Decree. The Law now provides for a general access by the public. However, access will be free only for the pledgors, the pledgees and others categories of persons or institutions to be listed in a Royal Decree. A fee to be fixed in a future Royal Decree will be due by all other persons to access the pledges register.
  • The deadline to bring a dispute concerning the allocation of the proceeds before a court is reduced from one year to one month as of the enforcement notification (Art. 64 Security Act). A one-year statutory deadline was considered too long in view of legal certainty and potential difficulties relating to the burden of proof. Interested persons to whom the enforcement is not notified will have three months as from the end of the enforcement process to file a claim before the court.
  • Article 107 of the Security Act provides for transitory provisions to transfer to the future pledges register, with their rank being maintained, the existing registrations relating to (i) agricultural privileges as registered in accordance with the Law of 15 April 1884 on agricultural loans and (ii) the pledges on business assets registered in accordance with the Law of 25 October 1919, provided that such a registration takes place within a period of twelve months after the entry into force of the Security Act.
  • Similarly, pledges on intangible assets (other than receivables) duly created before the entry into force of the Security Act remain valid. No transfer of registration is organized.

The Law also provides for certain formal changes which were required as a result of the evolution of the Belgian legislation since the adoption of the Security Act in 2013. For example:

  1. references to the « Law of 6 April 2010 on market practices and consumer protection »[1] are replaced by references to the « Code of economic law »;
  2. in the Collateral Law, references to the « Law of 22 March 1993 concerning the status and financial control of credit institutions »[2] are replaced by references to the « Law of 25 April 2014 concerning the status and financial control of credit institutions »[3];
  3. references to the « Mortgage Loan of 4 August 1992 »[4] are replaced by references to the « Code of economic law »; and
  4. references to the « the Law of 12 June 1991 on Consumer Credit »[5] are replaced by references to the « Code of economic law ».

2.   Changes to the law of 15 December 2004 concerning financial collateral arrangements (the “Collateral Law”)

When adopting (and revising) the Security Act, the Belgian legislator did not intend to impact the regime of security interest resulting from the Collateral Law. The Law therefore mentions expressly that the creation ofpledges on :

  1. financial instruments, cash or bank receivable within the meaning of the Collateral Law;
  2. fungible financial instruments within the meaning of the coordinated Royal Decree nr. 62 of 10 November 1967 relating to the custody of fungible financial instruments and the settlement of transactions in those instruments;
  3. dematerialised securities within the meaning of the Law of 2 January 1991 on the market of public debt securities and monetary policy instruments[6]; and
  4. dematerialised securities within the meaning of the Belgian Company Code[7];

may be made exclusively in compliance with the provisions of the Collateral Law. No registration in the pledges register will, therefore, be possible.

To compensate for the impossibility to register such pledges (and therefore avoiding the dispossession requirement), the Collateral Law will mention expressly that the security documentation may enable the pledgor to dispose of the pledged assets without affecting possession or control. This amendment aims to allow a dynamic management of the pledged assets.

The abovementioned provisions will enter into force on the date of entry into force of the Security Act.

3.   Registration Duties Code

Changes are made to the Registration Duties Code to ensure that, as from the entry into force of the Security Act, the registration of the pledges on business assets and agricultural privileges are exempted from registration duties. The ordinary regime provided by the Security Act will indeed apply to those pledges (Art. 34 Security Act). This amendment will enter into force on the date of entry into force of the Security Act.

[1] Loi du 6 avril 2010 relative aux pratiques du marché et à la protection du consommateur / wet van 6 april 2010 betreffende marktpraktijken en consumentenbescherming.
[2] Loi du 22 mars 1993 relative au statut et au contrôle des établissements de crédit / wet van 22 maart 1993 op het statuut van en het toezicht op kredietinstellingen.
[3] Loi du 25 avril 2014 relative au statut et au contrôle des établissements de crédit / wet van 25 april 2014 op het statuut van en het toezicht op kredietinstellingen.
[4] Loi du 4 août 1992 relative au crédit hypothécaire / wet van 4 augustus 1992 op het hypothecair krediet.
[5] Loi du 12 juin 1991 relative au crédit à la consommation / Wet van 12 juni 1991 op het consumentenkrediet.
[6] Loi du 2 janvier 1991 relative au marché des titres de la dette publique et aux instruments de la politique monétaire / Wet van 2 januari 1991 betreffende de markt van de effecten van de overheidsschuld en het monetair beleidsinstrumentarium.
[7] Code de droit des sociétés / Wetboek van vennootschappen.

Simont Braun’s Digital Finance Team assists mozzeno with the launch of its innovative platform

Brussels, March 2017

Simont Braun assisted the Brussels-based FinTech mozzeno on the launch of the first Belgian digital platform enabling individuals to participate indirectly in the funding of other individuals’ consumer loans.

The loans are financed through securitization, by issuing notes to which the investors subscribe.

In such a highly regulated sector, our team prepared the prospectus related to the continuous public offering of notes and ensured that mozzeno obtained the Belgian financial supervisor’s approval. We also collaborated with our clients towards maximum limitation of the potential risks for the investors.

Assisting mozzeno with the launch of its activities in Belgium demonstrates the sharp capabilities of our Digital Finance team, which is a pioneer amongst its peers in the quickly-evolving market of FinTechs”, comments Catherine Houssa, Partner and head of Simont Braun’s Digital Finance team.

Simont Braun’s team which advised mozzeno is comprised of partner Catherine Houssa, counsel Philippe De Prez and associate Lucien Standaert.

Media Contact: Nelly Chammas – – 02/543.70.80

The right to data portability and bank account information

In evolving to a Single Digital Market, the use of consumer data becomes more and more important for service providers. With regard to financial institutions, exploiting payment data is of particular interest, not only to reduce costs and improve product quality, but also to offer new and innovative financial services and, in general, an increased customer experience. The access to and the control over such data is therefore crucial. 

One of the ways by which the EU legislator wants to promote this is by mandating banks to “open up the bank account” to external parties. This is often referred to as the ‘access to account’ rule (‘XS2A’) which is for instance embodied in the revised Directive on payment services in the internal market (PSD2”).

Also from a consumer’s perspective, Europe wants to further strengthen a person’s control over his personal data and support the free flow of such data. This is one of the goals of the new General Data Protection Regulation (“GDPR”),and in particular the new “right to data portability”.

The GDPR applies from 25 May 2018. In order to bring further clarification for undertakings implementing it, the Working Party 29 (“WP 29”) recently published several guidelines. One concerned the right to data portability.

This article intends to give an overview of the most important points elaborated by WP 29 and, although the scope of this right concerns personal data in general, give particular attention to the portability of bank account information.

The main elements of data portability

Article 20.1 GDPR allows a data subject (e.g. a bank’s customer) “to receive the personal data concerning him or her, which he or she has provided to a controller, in a structured, commonly used and machine-readable format

and have the right to transmit those data to another controller without hindrance from the controller to which the personal data have been provided”.

The goal is thus to provide a data subject with the capacity to obtain, reuse and transfer its personal data from one data controller (e.g. Bank A) to another (e.g. a third party payment service provider such as an AISP).

WP 29 specifies that, in order for a controller to fulfill its obligations towards data portability, technical measures should be implemented to enable such ‘transfer’. This could be done by providing the data subject with the possibility to download the data or, at the request of the data subject, by sending the data directly to the other provider.

As is stated by the GDRP, the data should be provided “in a structured, commonly used and machine-readable format”. WP 29 does not give specific recommendations to this regard except, whatever format is chosen by the first controller, it should make the data interoperable and effectively useable for a second controller.

It is worth noting that executing its right to data portability, and thus transferring its personal data from one controller to another, does not mean that the ‘initial’ controller (e.g. Bank A) has the obligation to delete the transferred data. Unless, for example, a data subject would invoke its right of erasure (in accordance with article 17 GDPR), the controller is still allowed to retain the data for the initial retention period.

With regard to the receiving entity, he, as a data controller, shall of course have to process the acquired data in accordance with the provisions of the GDPR as well.

When does data portability apply?

As article 20.2 GDPR states, this right only applies for two processing operations. On the one hand, when the processing of the data is based upon the data subject’s consent or, on the other hand, when it is based upon a contract.

Moreover, the right only applies when it concerns processing ‘carried out by automated means’, thus excluding paper files.

Which personal data is concerned?

WP 29 sets forth three conditions.

First, the guidelines clarify it only concerns personal data related to the requesting data subject. Anonymous data or data related to a third party are excluded. However, WP 29 emphasizes the latter should be interpreted pragmatically. For instance, the transaction history of a person’s bank account can by principle be transferred by its bank, although the history shall contain details about third parties (i.e. the sender or receiver of the transaction).

Second, the right is limited to the data provided by the data subject itself. In this regard WP 29 points out that it should not be limited to data that is ‘actively and knowingly’ provided by the data subject, but also include personal data that are generated by and collected from the activities of the users. How extensively the latter should be interpreted remains vague. What is certain is that ‘inferred’ or ‘derived’ data are excluded. This means, for example, that if a data subject wishes to transfer all its personal data from Bank A to an AISP, it shall concern all data the data subject actively provided to Bank A (e.g. contact details, data about the transactions made via the account) as well as the data generated by using the bank’s services (e.g. an overview of all its bank transactions or location data). Other information the bank would have derived based upon the usage of their services and the data provided hereby, for instance a profile containing information on the consumer’s solvency, the number of credit transfers executed to a certain person, etc. does not have to be provided by the bank.

Third, the rights and freedoms of third parties may not be adversely affected. This means the execution of the right should be done in respect to personal data concerning other data subjects.  WP 29 gives as an example the transmission of a bank account history. If the concerned data is processed by the second controller for the same purpose (i.e. as ‘bank account history’) such processing does not give rise to any legal problems. This would however be the case if the data related to the third party would be used for another purpose, such as marketing. The execution of the right to data portability should also be with respect to data covered by intellectual property and trade secrets.

Some other obligations for the data controller

The GDPR explicitly obligates data controllers to inform the data subjects about their different rights under the Regulation. One must thus be notified about the existence of his right to data portability and how it differs from other rights under the Regulation. This should be done at the time when personal data are obtained, but WP 29 recommends to include such information also before any account closure.

Furthermore, a controller is not allowed to charge the requesting data subject a fee, exceptional circumstances left aside.

Finally, a data controller should implement an authentication procedure in order to confirm the identity of the data subject requesting to execute its right to data portability. This can, for example by using passwords or a digipass, which are already common practices in the banking sector.

To conclude, in order to give a person more control on its personal data, the right to data portability is one of the means by which the EU tries to achieve it. As the European Banking Association (EBA) recognized in its Discussion Paper on innovative uses of consumer data by financial institutions,

allowing the portability of consumer data would significantly reduce the risks for a “lock-in” with one single service provider and, as a consequence, foster competition. What the effects will be in practice, in particular in combination with the XS2A rule under PSD2, will be seen as of 2018.

For further information, please contact Simont Braun’s Digital Finance Team: – +32 (0)2 543 70 80