Equality for EBICS – use case instant bulk payments

Even if it might appear strange at first sight: in Germany, instant payments use cases for the file-based EBICS transfer protocol are also currently being discussed and specified for the customer-bank relation.
In this case, the use cases focus on the corporate customer business. Particularly larger corporate customers are required to be able to transmit bulk uploads to the financial institutions. Hence, for SEPA credit transfer uploads, for example, the German banking industry has agreed on the special form of a bulk instant payments upload (instant bulk payments) based on the XML format ISO pain.001. Equivalent business transactions and formats (payment status in the pain.002 format, for instance) are also being defined for the return direction of payment information in the payment chain – from the recipient or the financial institutions. The business transactions and format specifications thus defined are expected to become officially valid in Germany from November 2019 and can be offered by the financial institutions as an option.

What is special about instant bulk payments?

The key feature distinguishing instant bulk payments via EBICS from, for example, pure instant payments processes that are synchronously executed at the "point of sale" lies in the fact that the upload itself is not considered "instant" but is taken to be an upload for execution as instant payments (SCTINST).
The submitter's executing financial institution breaks the collection file down into single transactions and executes the payments as SCTINST provided the creditor can be reached in this way. The terms and conditions of SCTINST only become applicable from this point in time.
The return-direction data is then transmitted back to the submitter by the submitter's financial institution again using the EBICS channel. In this case for the default, this means that the data is provided by the financial institution for downloading in the EBICS bank server. In the corporate customer business, the financial institution exclusively assumes the familiar passive role in the relation between customer and financial institution defined for EBICS. Therefore an active notification of the sender via EBICS is currently not planned. 

Instant bulk payments due to urgency? 

Corporate customers want to use the new business transactions to enable payments to be collected and simultaneously submitted at short notice. In this way, the money can be used for longer periods until submission. The payments are then also immediately guaranteed and executed.
As with the recipient side, immediate notification is also desired for the return direction. As no provisions have been made in the EBICS role model for financial institutions to actively notify the customer, various interfaces (APIs) and procedures (such as e-mail push) are currently being discussed for this in Germany. 

Yet it is actually quite simple: why not make use of the bilateral EBICS that has already been established for interbank payments? Both parties, customer and financial institution, have equal roles as sender and recipient. All that is needed is to extend the EBICS customer applications by adding simplified EBICS server functions. Corporate customers uploading instant bulk payments could then also actively receive data from these processes. Applications of this kind are already available on the market. The new business transactions are therefore fully implementable using the existing standard and based on existing solutions. This could put an end to the time-consuming and costly discussions about additional interfaces, protocols and agreements.

Michael Lembcke

10 years of EBICS – a success story

At the start of 2008 it was finally time: From this point onwards, every corporate client in Germany could be sure of being able to reach all banks and savings banks via the Internet by means of a standardised, secure electronic banking procedure in order to send bank transfers, direct debits and other orders and obtain account information. Multibank capability, very important for corporate clients, was guaranteed by the DFÜ agreement of the German banking industry (DK), which, starting from 1 January 2008, obligated all financial institutions in Germany to support a new, standardised procedure known as EBICS (Electronic Banking Internet Communication Standard) for their data exchange with corporate clients.

Even though it was already clear at that time that EBICS was going to be successful, there was no predicting the scale of the EBICS success story. EBICS is now a European standard for secure data exchange, not only in electronic banking with corporate clients but also in interbank payments, and it is additionally in line to become the standard for current developments such as instant payments. But more on this later.

The pre-history: the road to EBICS

EBICS, to be precise, is more than 10 years old, as it came into being on 18 July 2003. This was the day on which SIZ GmbH presented an Internet-based electronic banking procedure at a special meeting of the ZKA (Central Credit Committee = old name of the DK) with the aim of promoting this procedure, or at least the design basis of this procedure, as the basis of a new, multibank-capable Internet standard for the entire German banking industry. Since 1995, the DFÜ agreement of the ZKA guaranteed a multibank-capable procedure, BCS-FTAM, for the corporate client business. However, this file transfer procedure was based on the OSI standard FTAM for X.25 and ISDN connections, and in the Internet age it was no longer state-of-the-art. Despite a number of attempts since then, it was not possible to establish a common IP-based standard. There were manufacturer-specific (e.g. MultiWeb, MCFT) and association-based solution approaches (BCS-FTP), but they lacked the decisive element: multibank capability. On 18 July 2003, the time seemed ripe for a new standard. A DK working group formed spontaneously at the special meeting, and its mission was to develop a common, IP-based, multibank-capable communication and security standard. EBICS was created based on the design of WOP. The draft concept created by the working group was the basis forthe EBICS specification, version 1.0 of which was already presented in the middle of 2005.

EBICS was not a revolution, being based from the start on an evolutionary concept. The elements of BCS-FTAM that had proven themselves for more than 10 years were kept, and only those elements that were no longer state-of-the-art were redesigned. Therefore, the concept of order types, and thus application-neutrality, was kept on board along with the authorisation of payment data via electronic signatures (ES). What was new about EBICS in particular was the replacement of the X.25- and ISDN-based communication of BCS-FTAM with a state-of-the-art XML communication protocol based on Internet standards. Additionally, the EU was extended to the distributed electronic signature (EDS), which enables corporate clients to authorise orders which, for example, are transferred automatically from the accounting department to the bank, at any time and from any location, and to also use mobile terminal devices.

SIZ GmbH initiated the development of EBICS in 2003, and has been accompanying it continuously ever since. In 2005 SIZ became the control centre of the German banking industry for EBICS (Appendix 1 of the DFÜ agreement) and for the data formats in electronic banking and payments (Appendix 3 of the DFÜ agreement).

In 2006, the savings bank financial group became the first institution group in Germany to support EBICS comprehensively. Then, in 2007, the associated and public institutions followed, along with the big banks and other private banks.

EBICS: the secure tunnel in insecure networks

The basis for the development of EBICS was above all a detailed security concept. Because data in electronic banking and payments requires special protection, the potential threats were used to derive security requirements and security measures for EBICS that use various cryptographic measures to guarantee the confidentiality, integrity and authenticity of the data in potentially insecure networks (e.g. the Internet). The confidentiality and integrity of the data was ensured by means of an EBICS-specific encryption procedure which, in addition to the TLS encryption on the transport level, also offers end2end encryption of the sensitive data in electronic banking. The authenticity of the communication is provided by the authentication signature of every data package. The authorisation of payments is ultimately given via electronic signatures, whereby depending on the contractual agreement between customer and bank, different authorisation models can be used (single and multiple signatures, ES classes, limits etc.). The security concept has been checked regularly ever since, with EBICS being further developed if required in order to adapt the procedure to new or altered threat situations and/or technical standards. Over the years, EBICS has proven to be an extremely secure standard: To date, no successful attacks on EBICS have been confirmed.

The ground-breaking features of EBICS for the secure transfer of sensitive data:



2008: introduction in Germany

On 1 January 2008 the time had come: With the DFÜ agreement of the German banking industry, all banks and savings banks in Germany committed to supporting EBICS on the bank side from this date onwards. EBICS was accepted by the corporate clients faster than expected: in the first year already, a majority of corporate clients switched from BCS-FTAM to EBICS. Clearly the advantages of the new procedure were just too big. The runaway success of EBICS was mainly due to the fact that the transmission speed of the IP-based EBICS was many times faster than that of FTAM, that the use of Internet standards greatly simplified the incorporation into company and banking networks, and that EBICS offered new features such as the distributed electronic signature. It was decisive, however, that the DFÜ agreement of the DK guaranteed the multibank capability that was crucial for corporate clients from the very beginning. The switch was made easier by the fact that migration scenarios were already implemented in the procedure which made it possible to convert the keys for the electronic signature from BCS-FTAM to EBICS practically at the touch of a button.

EBICS develops into an interbank procedure

Word travelled quickly that EBICS is a very secure procedure especially designed for safe, fast transmission of large data volumes. So it was no surprise that EBICS also became the communication standard in interbank payments. The trailblazer here was the German Central Bank, which introduced EBICS in 2008 as the communication procedure for the SEPA Clearer within the scope of the the RPS (Retail Payment System). At this point it is impossible to imagine a secure exchange between banks and clearing houses without EBICS. Along with the Central Bank, the EBA clearing in the STEP2 payment system also uses EBICS, and EBICS has also been established in bilateral clearing between banks, so-called "garage clearing”, for many years now.

EBICS was also very quickly introduced for the delivery of data by service data centres. In 2009 the corresponding DK guideline relating to the support of EBICS was issued.

EBICS becomes the international standard

By the end of 2006 the French banking industry (CFONB) became aware of EBICS when looking for a new, secure, IP-based communication procedure. Similarly to Germany, France was faced with the situation of replacing an old standard (ETEBAC) with a future-oriented procedure. After intensive evaluation of various alternatives, EBICS emerged as the suitable procedure, and in 2008 a co-operation between the French and German banking industries was initiated. In summer 2010, EBICS SCRL, the European EBICS association based on Belgian law, was founded in Brussels. EBICS has now been introduced just as widely and successfully in France as in Germany. With the foundation of the EBICS association, the SIZ became the official technical office of the association (European EBICS control centre) and has since coordinated the EBICS working group, i.e. the committee responsible for the further development of EBICS.

However, with the introduction of EBICS in France, different “dialects” became established in the two countries. For practical reasons, it was accepted that due to the different requirements in the two countries, there would also be different versions of the EBICS standard. This related in particular to the representation of business transactions, for which the three-character order type ID is used in Germany, whereas in France they are identified by means of format parameters. There were also other differences, e.g. in France the cryptographic keys used are based on the X.509 standard, while Germany continues to employ a proprietary format that comes from BCS-FTAM. And while both countries were basically “speaking” EBICS, the inter-country compatibility faced some problems because of the different “accents” being used.

This shortcoming became really apparent in 2015 when Switzerland became the third country to join the EBICS association. Switzerland was presented with the dilemma of choosing between the “dialects” or even adding a third, Swiss “accent”.

If was obvious that different EBICS dialects were not conducive to the desired proliferation of the standard in Europe. The only solution was to harmonise EBICS, and this need was finally addressed in the new EBICS 3.0. In particular, the introduction of BTFs (Business Transaction and Formats) enabled a future-oriented, flexible and above all standardised identification of business transactions for EBICS. It was also possible to achieve further important harmonisations in the EBICS standard, thus making EBICS a uniform international standard. With electronic payments it is especially important for partners to be able to reach, understand and trust each other. The understanding is achieved mainly by the common SEPA data formats and the standardised EBICS identification via BTFs, the accessibility and trust is given with EBICS as a common communication and security standard. EBICS 3.0 has been released and can be introduced in autumn 2018. In Germany, EBICS 3.0 will be mandatory for all institutions of the German banking industry from 2021, as per the DFÜ agreement of the DK.

10 years of EBICS: review and outlook

It’s time to look back on 10 years of EBICS in Germany. What began as an attempt to contain different, incompatible developments in electronic banking in Germany, and ensure the multibank capability for corporate clients in the Internet age, has developed into a success story that has long traversed the nation’s borders. EBICS is known worldwide as an open standard for the secure exchange of files, and is also used in countries that are not (yet) members of the EBICS association. EBICS is now not only a customer-bank procedure but an established standard in interbank payments, and it is also expected to play an important role in both the submission and clearing of instant payments.

But what are the reasons for this long-running success? It seems to me that the following points in particular have been decisive:
  • The application-neutrality of EBICS
    EBICS is application-neutral and can transfer the widest range of data types, because neither formats nor bank-technical specifications were incorporated into the design of the transfer protocol. This is why EBICS can be used so easily in different countries and different application scenarios.
  • The security features of EBICS
    Because EBICS combines mutually independent cryptographic procedures for data confidentiality, the authenticity of the partners and the communication, and for the authorisation of orders, it offers a secure tunnel in insecure networks.
  • The multibank capability
    Both in Germany and in France, EBICS is a multibank-capable procedure. In Germany, multibank capability is guaranteed by the DFÜ agreement of the DK.
  • The adaptability of EBICS
    As an open standard, EBICS has an architecture that can be adapted to different requirements, and it is continuously being developed further by the EBICS association.
EBICS has a lot of history behind it, even more than the 10 years since its mandatory introduction in Germany. But the story is far from over: As an open, secure communication standard, EBICS has a bright future ahead. With the experience of seeing that the fundamental design decisions are still holding up today and that the flexibility of the procedure enables EBICS to be adapted to new requirements, we can be confident that EBICS will continue to be an important element of electronic payments in Europe.

Dieter Schweisfurth

Head of Electronic Banking
SIZ GmbH

EBICS in “private banking” – use cases beyond payments

EBICS is widely regarded as secure transfer protocol for the exchange of payment files (orders and statements). For corporate customers in particular, it is certainly the most commonly used protocol. At this point I would like to present a different use case that is very relevant in Switzerland: EBICS in the private banking sector.


The private banks here are currently going through an even rougher patch than before and are under a lot of pressure from various sources. Regulations, margin pressure, better informed customers, breaking up the value chain, and the digitalisation process are only some of the many topics currently found on the agenda of private banks' boards. In the area of automation, we are observing a noteworthy initiative in Switzerland – the use of EBICS as an interface for stock market transactions.

At the suggestion of big institutional investors and professional asset managers, who, for their part, also have an interest in higher automation, more and more EBICS transaction types from the order business are being offered recently. Typically, these are order types for submitting and processing stock market orders (upload) and for order confirmations, invoices and deposit statements (download). The formats used are SWIFT (MT5xx) and PDF. They are implemented as institution-specific order types (XYZ).

Now, if we take a look at the entire value chain of a stock market transaction, it can ideally be performed in a fully automated manner. The portfolio management system of an asset manager detects an imbalance between the investment strategy and the customer's portfolio, and generates the stock market order for a reallocation. By means of the standards EBICS and SWIFT (for example, MT502), the order is triggered automatically at the institution, and the confirmation is reported back via EBICS, as well (for example, MT509). The automation substantially reduces the processing work on all sides. Additionally, the error quota is lowered significantly compared with the manual processes that are still widely used to this day.

In summary, innovative private banks are already offering EBICS or planning to join the market with their respective offers shortly. As, traditionally, payments take a less dominant role in the private banking business than in universal banks, the focus of EBICS shifts to stock market transactions and asset reporting. As asset managers and institutional investors also strive for higher automation, it's a win-win situation. It would be ideal if the standardisation bodies agreed on universal and uniform order types (or, as of EBICS 3.0, the so-called BTF specifications) and defined formats as soon as possible.

Carsten Miehling

EBICS 3.0 with BTF clears the way

European payment transactions are converging thanks to SEPA and EBICS. With the help of EBICS 3.0, various EBICS dialects are now merging. The concept behind this process is called BTF. BTF stands for Business Transaction Format. BTF standardises the description of the formats to be transferred in Germany, France and Switzerland. This harmonisation clears the way for a growing EBICS community.


The new EBICS 3.0 specification is valid as of 27 November 2018. The launch dates can vary in the individual countries. EBICS 3.0 will bring about the following standardisations:

  • A standardised EBICS version in the individual three EBICS countries
  • A unified identification of the business processes and formats (BTF)
  • A standardised X.509 format for the key deposition
This is how the compatibility of the EBICS dialects will be guaranteed.

Optional features

Up to the present, not all of the EBICS features were offered in all of the countries, whereas now, with EBICS 3.0, banks can offer their clients all optional EBICS features individually.
These include:
  • Certificates
    CA-signed certificates
    Self-signed certificates
  • Model of authorisation
    German T, A, B and E authorisations
    French T and TS authorisations
    Elimination of the fax authorisation
  • Distributed electronic signature (VEU)
    The use of the VEU is mandatory in Germany but otherwise optional
Innovations

The EBICS 3.0 specification includes innovations which have to be taken into account upon introduction.
  • Mapping
    The adjustment of format parameters and order types to BTF standards is simplified by assignment overviews (mappings). These mappings for order types and format parameters are defined on a national scale. The EBICS clients have to put these assignments into action. In the meantime, there might be some variances: bank A already supports BTF while bank B only offers EBICS 2.x.
  • Extended control
    With the aid of BTF, it is now possible for the EBICS client to control the bank server. Up to the present, the bank server exclusively controlled these processes, but with this client control a new chapter opens up. The EBICS user can decide if his assignment goes directly into the VEU or if the authorisation should be checked. The EBICS specification defines the action in case of any differences between the BFT specification and the rights on the bank server.
  • Standard protocol
    The strategic customer protocol in the EBICS 3.0 specification is the HAC. By that, the old text-based customer protocol PTK will be replaced entirely. The HAC protocol is machine-readable because it is based on XML. Throughout the transitional period, PTK and HAC will co-exist given a mix of EBICS versions. According to the EBICS 3.0 specification, BTF orders won’t be displayed in the old PTK anymore. Nonetheless, for all those who would still like that, the PTK format can be extended proprietarily.
EBICS 3.0 paves the way for a growing EBICS community

EBICS 3.0 Europeanises the use of EBICS. That’s a good development because this way, banks can win over new markets and clients. The user profits from this flexibility by gaining new possibilities. EBICS now uses established standards exclusively.

The existing interfaces and contract conditions can almost remain unchanged. The BTF can be configured in the background. As far as bank servers and EBICS clients are concerned, business standards are still a priority. This is supported by the EBICS 3.0 specification and the mapping defaults.

The introduction of EBICS to new markets and countries has been simplified enormously by EBICS 3.0. The advantages of EBICS 3.0 are obvious. Therefore, a near-term introduction in the existing EBICS countries is recommended.

Michael Lembcke

EBICS 3.0 in the starting blocks

On 19 May 2017 in the auditorium of the Fédération Bancaire Française (French Banking Federation), a workshop was held by CFONB to present version 3.0 of the EBICS protocol.

More than 120 people from various industries - banking, manufacturing, business etc. - took part in the event at which different speakers discussed the basic concept of this new version.


After the CEO and a number of representatives of EBICS SCRL (www.ebics.org) had provided an overview, a selection of important historical dates for EBICS was presented. They reminded us that the EBICS standard is well out of its infancy by now, as the implementation in Germany started 12 years ago and EBICS had its début in France more than 7 years ago. The Swiss financial institutions only started along this path in 2015. One presentation showed the current prevalence of EBICS, extending from the Iberian peninsula to the Baltic and from Ireland to Italy. However, aside from Germany, France, Switzerland and Portugal, the degree of usage in the countries of this region differs very significantly.

We were then presented with the reasons for the success of EBICS in the four countries (you will find numerous articles on the topic in this blog) and the barriers to its rapid expansion throughout Europe. The most significant of these are:
  • The differences in the identification of the payment flows between German, French and Swiss variants
  • The use of X.509 certificates in France and key pairs in Germany
  • The use of the distributed electronic signature in Germany and Switzerland, but not in France
This list was followed by a description of the profound changes that version 3.0 will bring, in particular with regard to the harmonisation through the integration of the BTF (Business Transaction Format) concept and the possible generalisation of the distributed electronic signature. You will find more detailed information on these topics on the EBICS SCRL website.

The second part of the workshop was a discussion on the topic: Why do we need a standardised EBICS version?

This presented stakeholders from the EBICS area with the opportunity to raise and discuss the following topics:
  • The advantages of EBICS and the limitations of version 2.x due to a lack of harmonisation
  • The expectations for the new version and the advantages provided by the harmonisation
  • The opportunities to expand geographically, even to other continents
    Africa in particular was mentioned here because a number of its banks already offer the EBICS service in several French-speaking countries.
  • The opportunities to use EBICS beyond the company-bank relationship
    Particular mention was made of the use of EBICS for STEP2 and RT1 (instant payments) with EBA Clearing.
  • Migration modalities
  • Aspects of the future development of the protocol under discussion that can be put on the agenda, such as the standardisation of the AC certificate and the option to use certificates that are not saved on physical media in order to simplify the industrialisation of EBICS signature solutions for mobile devices.
  • The current use of the distributed electronic signature in Germany and Switzerland, and the advantages that its use in France could bring
So this event comprised the official introduction of version 3.0. It will be available from November 2018, from which point all banks must offer the new version in addition to version 2.x, which is valid in the various communities.

There is no obligation for companies to also migrate at this time. There is no plan for them to perform a sudden migration from 2.x to 3.0. However, the new communities could start using this new version immediately.

Manufacturers and banks are faced with the prospect of a lot of work. In July 2017 an implementation guide will be provided by EBICS SCRL and CFONB to help with this process.
I give many presentations on EBICS in various European countries and beyond, and I believe that the harmonising will make this product significantly easier to promote. I am convinced that it is the key to success, and that the first letter of EBICS will come to signify “European”.

What if the developments currently being tested led to the next step being a Worldwide EBICS?...

Marc Dutech

EBA CLEARING to introduce EBICS as additional connectivity option for its instant payment system

Future service participants can use SIANet or EBICS to connect to the new pan-European real-time payment infrastructure from November 2017 on – other options may follow later.

EBA CLEARING announced today that the future participants in its pan-European instant payment infrastructure service will be able to use, in addition to SIANet, the Electronic Banking Internet Communication Standard (EBICS) for the exchange of transaction messages with the platform. The Company will introduce EBICS as an additional connectivity option from the start of the service in November 2017 and make it available in the test environment from June 2017.


Read the press release from 9 March 2017 here: EBA CLEARING press release

Michael Lembcke

How to enhance EBICS, Part 9 – EBICS is ideal for transferring files of all sizes. – Yes, but …

The data behaviour for payments also continues to change with SEPA. New processes mean that the files exchanged between customers and banks and in bilateral exchanges keep getting bigger. In the customer-bank relationship in particular, the download function for data downloads (e.g. account statements) via EBICS plays an important role. And here at least there seems to be a need for optimisation. For particularly large files, various factors make it difficult to perform a successful download.


To describe the problem more precisely, one first has to take a closer look at the EBICS protocol. Downloads via EBICS are performed in segments, always for all of the data that is relevant to the client request. When it receives a request, an EBICS client always puts all of the data for a download in exactly one physical file.

In the EBICS download process, after a download order is received the EBICS-Server first determines the number of segments in which the file to be transferred will be transferred to the client. This number is returned to the client with the first segment. It is mandatory in EBICS. Then the client calls up every subsequent segment sequentially and creates the file in the client.

Depending on the file size and the delivery type (e.g. ZIP archive), even the operation of compiling the first segment with the total number on the EBICS-Server can take some time. First, the complete file must be created in a compressed and encrypted form so that in the first EBICS response the correct number of segments can be delivered to the EBICS client. Therefore, until the client receives feedback on the number of segments in the initialisation phase, timeout situations and thus terminations can occur in the EBICS connection when large data volumes are involved.

This is the problem. In future, therefore, it must be possible to speed up the EBICS response to the EBICS initialisation request.

It is currently seen as imperative for the number of segments, which is returned to the client with the first segment, to be correct so that the transfer can be started. However, according to EBICS specification 2.5 (see section 7.2 Implementation in the EBICS messages, page 159), if the segment number specified is incorrect the EBICS client should behave tolerantly. In such a case, the EBICS client should proceed with the ongoing transaction with the acknowledgement phase, even if the EBICS-Server delivers fewer segments than it specified in the initial EBICS response. It should be possible to determine and return an estimated number of segments so that the EBICS-Server provides feedback to the client faster and avoids a timeout in the case of large files.

Fundamentally, it would be desirable to extend the EBICS specification with the following two partial solutions.

The EBICS client initiates a download of an unspecified size to avoid timeouts due to large data volumes

In its response, the bank server returns a number of segments for the expected data along with the first segment. If the data involved enables a faster compilation procedure, the bank server can deliver the exact number of segments as it has done up to now. However, if a larger data volume is involved, and possibly a longer preparation time (e.g. ZIP), it is permissible to return an approximate number of segments.

In any case, the EBICS client must keep calling up segments until it receives the end message.
In order to avoid timeouts during downloads in the collection/preparation phase of the EBICS bank server, when calling up a subsequent segment the EBICS bank server should also be permitted to return a value that indicates that it has not yet completed the data compilation. The EBICS client can keep requesting the required segment until it receives this segment.

Optional limitation of the data volume to be downloaded by the EBICS client in order to avoid files that are too big

At the same time, downloading large data volumes can also be problematic due to conditions outside the sphere of influence of the EBICS-Server or its operators. The problems can be caused by the system design of the client or the infrastructure. In such cases, it can be helpful if the data volume to be called up on the customer side can be restricted further than the current options allow (historical call up).

For example, it would be desirable for the EBICS client to be able to specify a maximum size when initiating a download. A possible solution would be a new optional parameter for the size of the download data. During the download, the EBICS bank server then always delivers complete data blocks (e.g. an account statement), and at least one of these data blocks. The size restriction should always be interpreted as a guideline value that the bank server is also permitted to exceed. This would provide an additional possibility, aside from the historical download, to control the size of the download data on the client side.

With these two extensions, EBICS will be equipped to deal with the growing data volumes in the future as well.

Michael Lembcke