Taken as a whole, we very much welcome this proposal of NLF Directive and its objective of harmonising the legal framework for payments in Europe. Its coverage is good and successfully manages to identify the sorts of topics that need to be included so as to facilitate the development of the actual payments systems and processes by the commercial sector. There are numerous points of clarification or drafting points, but there are certain key points which very definitely need to be addressed and which are potentially contentious since the customer view may well differ from the banks’ view.

The purpose of this document and its annex is to communicate the views of EACT and certain requests for modifications to the bodies – the European Parliament, the European Council - that will be called upon to enact this directive.
EACT is willing to discuss any of the following points in further detail with the interested parties.

The 8 following points are those that we consider essential while the annex deals with more specific subjects or details some of the essential points.

1. Exclusion of companies from the provisions of the Directive (Title III and IV).

Companies are “virtually” excluded from the Directive on the basis of the transaction limit of 50.000 euro and “explicitly” excluded by provisions regarding losses from unauthorised transactions and refunds.

Art 2 stipulates that “… for payment services where the amount of the transaction exceeds € 50.000, Titles III and IV shall not apply “ The reason for the exclusion is stated in the introduction Page 11 (6) “…..some provisions should not apply to transactions above a certain amount since the user is likely to be in a position to negotiate more specific and more appropriate terms and conditions with the payment service provider”

Art 51 stipulates that articles 49 (provider liability for losses in respect of unauthorised payment transactions) and article 50 (user liability for losses in respect of unauthorised transactions) “…shall not apply where a payment service user is an enterprise exceeding the size of a micro enterprise….”


EACT feels that the Directive establishes general principles that should apply to all payments
and all payment users.

If companies were subject to all provisions, only the rule in art 50 that the customer is only liable up to EUR 150 would need to be changed .For companies the limit could not exist, be raised to a higher amount or differentiated according to the size of transaction, e.g. above or below EUR 50.000.

As a waiver, users which are companies and payment service providers should be allowed to agree on different terms and conditions from those provided in the directive.

2. Directive gives too much lee-way to member states in implementation There are numerous passages in the Directive where Member State are allowed to modify or derogate from the provisions .This possibility might lead to significant differences from one Member state to another Member state; the primary objective of SEPA – one single payment area – might not been achieved.

More specifically, EACT believes that:

• it would be judicious in our opinion that the same institution be in charge, in each country, of supervising banks in the area of payments as well as payment institutions and impose the same supervisory constraints to both (article 15).
• no payment institution should be registered in a given Member state if it does not satisfy all the obligations attached to that status even if it is allowed to only operate in that Member state.

3. Definition of payment service providers

EACT wants to be assured that SSC, Payment Factories and Group Treasury, handling transactions on account of group companies are not considered under this Directive as Payment Institutions subject to regulatory requirements
Article 1 should explicitly exclude these entities from payment service providers.

4. IBAN as unique identifier to credit account is too risky

In Article 4 definition 15, the Directive leaves the choice of a “unique identifier” to identify payment service users. For payments to bank accounts the choice is between IBAN, BIC, BBAN and name of the account owner.

In Article 66, the Directive mandates that when IBAN is used, banks will credit the amount without necessarily checking the conformity with the name of account owner, if provided

EACT would like it to be the responsibility of the payment service provider to check that the IBAN code matches the name of the IBAN code holder.

The wording of the definition (15) of article 4 of the unique identifier should therefore be amended to specify that this unique identifier includes both an IBAN code and a name. In such conditions, the bank account number in addition to the IBAN would be superfluous.

Article 66 should indicate clearly, for the payment service provider, the obligation to check that the IBAN code corresponds to the name. If they do not match, the service provider must not execute the payment and must notify the payer. The service provider would be responsible for any payment executed where the IBAN and the name do not tally. In our view this provision is essential, not only to reinforce the security of the system but also to help combat fraud and money-laundering.

We understand that STP is easier when only a code must be processed but this cannot be done to the prejudice of security.

EACT has made a proposal that name /address be substituted by a code identifying the account owner .In each country, this code could be the same as the one identified by the FATF GAFI legislation.

This is the problem of Digital Identity, which is much needed not only for payments but to enable the entire e-economy
A last point concerns BIC; EACT is of the opinion that for domestic (and possibly all) payments BIC should be applied to payments by the banks on the basis of the IBAN provided by the user

5. Ambiguities and differences in EPC Rulebooks and NLF Directive regarding dates and cycle-times

As a rule, we believe that dates and cycle times agreed in the NLF should command to those mentioned in the EPC Rulebooks. And the definitions should be identical.

For instance:

• In the EPC CT Rulebook the execution time is D+ 3 where D is point in time of acceptance while the Directive mandates a maximum one-day execution, without explicitly saying what is meant by execution.

In Title IV, Chap 2 “Execution time”, it clarifies that the “amount must be credited to the payee at the latest at the end of the first working day after the point of acceptance”.

In Chap 1 it says that “the point in time of acceptance shall not be later than the point in time when the payment service provider starts to execute the payment transaction “ ....In the case of electronic payments the acceptance must be explicit..

The point in time of acceptance happens when (Art 54) “the payment order has been received and authenticated and the Service Provider has explicitly or implicitly accepted the order”

This seems to be a bit of a circular reasoning ….. execution happens max +1 working day after acceptance …and acceptance can happen no later than execution ….

- Article 55 says that “Refusal of a payment order must happen within three working days of the point in time of acceptance”

The wording is unclear … at the point of acceptance, the order should either be accepted or refused . Does “refusal” include rejects from clearing and also returns from the receiving bank? Either 1) the bank delays acceptance and execution while evaluating the order or 2) has given acceptance and started execution but settlement does not occur ( Rejects ) because the clearing send it back or 3) it comes back after interbank settlement ( Returns )

In the first case, the originator bank is holding up the acceptance and the execution of the order, and if it finally accepts it. Maximum execution time of D+1 is exceeded …

In the second and third cases, the originator bank had accepted and executed the order …
Whenever Credit Transfer and Direct Debit are considered together, some ambiguity is always likely to creep in.

We notice that neither the EPC Rulebooks nor the NLF Directive take into consideration the Point in Time of the original order , even though , a major factor of delayed payments is the originator bank handling time of the order.

In electronic and paper payments, time of receipt of order is always recorded and is the real starting point of the payment process.

Lastly, EACT would have preferred that the Directive defines “execution” rather than leave it to contractual agreements with Payment Service Providers

• For Direct Debit it is difficult to relate the Directives provisions to the EPC Rulebook, which ,to define its work-cycle, focuses on Due Date rather than acceptance date.

Article 61,1 of the Directive says that the amount ordered must be credited to the payee at the end of the first working day following the day on which the point in time of acceptance falls.

But the EPC Rulebook does not consider acceptance as a specific point in time and does not foresee an explicit acceptance of the order .The Rulebook does not say on which date the creditor will be credited, only de debtor (D or D+1LBD if D is a local banking holiday )

Further, according to the Directive (Art 61,2), if the payer service provider refuses to release the funds, the payment service provider ( of the payee ?) will notify the payee within the same time ( D+1 where D is acceptance ) . According to the Rulebook, the debtor bank has up to 5 working days to send back information to the Clearing house that it refuses the debit.

-We have appreciated the fact that the Directive sets the max. period for refund in four weeks from the moment the payer is being informed of the debit. In EPC Rulebook the period is three months from date of debit Still the “moment the payer is informed “ is a “variable point in time” . The only certain date is date of debit .

6. Value dating

If value dating is banned as a non transparent way of charging for services, debit and credit dates should always be equal and equal to settlement date.

Credit Transfer

Article 60 affirms that in credit transfer the payee must be credited, at the latest, at the end of the first working day after the point in time of acceptance, which should coincide with date of execution and settlement. Nothing is said about the value of debit

The EPC rulebook says that the credit must occur, at the latest, on Settlement day + 1 and does not specify the debit date

Direct Debit

Article 61 uses the same formula of credit transfer to define date of credit for direct debit but adds that the credit date can be different if explicitly agreed between payee and his payment service provider.

The EPC Rulebook fixes the debit date but says nothing of the credit date

Room for float

If one end of the transaction is open, there is still room for banks to benefit from “float” and there could be differences from country to country.

This contradicts the “ban value dating” philosophy espoused by the Commission

7. Insufficient information to be provided to payer and payee

Time of order, acceptance/refusal and execution must be recorded by banks in their internal systems, as it must be possible to monitor compliance with time-cycles and minimum service levels, as mandated by the NLF Directive and the EPC Rulebooks.

The beneficiary is the party who most directly bears the consequences of poor service and the only one who, being at the end of the cycle, could measure respect of execution time On the other hand, the payer wants that payments are executed in time so that he complies with his contractual obligations .He has an interest in that the beneficiary can identify delays due to the banks and not to him.

Articles 36 and 37 define some but not all essential elements of information that must be provided to the parties.

In addition to the elements listed in the directive (marked by *) we would like the bank to report

To the Payer, after execution

Bank transaction code
Book date of debit
Value date of debit
Order date/ time (to check respect of cut-off times)
Unique transaction ID * (assigned by payer; for individual payments (not in batch) is also called URI, the cross reference for remittance advice sent separately)
Bank transaction ID (assigned by bank/ clearing)
Beneficiary
Amount debited*
Original amount transferred *
Currency*Exchange rate * (if converted)
Original amount transferred*
Detail of commission, fees and charges* ( paid by the payer )

To the Payee

Bank transaction code
Book date of credit
Value date of credit
Order date/time*
Unique transaction ID * (URI) or Remittance information
Payer
Amount debited*
Original amount transferred *
Currency*
Exchange rate * (if converted)
Original amount transferred*
Detail of commission, fees and charges* (paid by the payee)

8. Article 77 “Payments Committee”

EACT welcomes the creation of this committee but understands that it is composed exclusively of Member States representatives. EACT believes that it is crucial to establish a committee or body where all stakeholders (regulatory authorities, payment service providers, users and therefore corporations) would be able to exchange their views on the Directive.

ANNEX

SPECIFIC OBSERVATIONS

The specific observations are listed following the order of the Directive, including explanatory memorandum and preamble.

Where the comments have already been reported under the 8 essential points, they will not be repeated.

Explanatory Memorandum

Pages 2,3

Reduction in unit cost level to 20% above best practice level = € 10 billion savings
( helps banks cut losses from drop of revenues …)

€ 100-200 billion a year gains. It is not clear at all where these gains come from: cross border payments? e-invoicing? Dematerialization of all trade documents? Including e-reconciliation?

Footnote . Visa study showing +0,5 % increase in consumption for each 10% increase in share of electronic payments … Because pay faster is buy more ? ? No credit considerations?

SEPA for banks should be complete by 2008…..It is not clearly stated but banks should have all systems in place by 2008; payment users, including companies are not obliged to be ready until 2010.

2-3% of GDP is cost of payments … banks bear a large share of this cost …. spending one third of their operating costs on payments .. but they have revenues against these costs ?

One must always remember that, in the end it’s always payment users who pay the whole cost. Banks charges cover all costs and banks make money on payments.

Consumers are complaining about the effect of fragmentation on them.

In some member states, retailers pay for collections up to 5% of their card sales

Companies are unable to integrate their invoicing with payments ….

The problem exists at the domestic level too, where there is no fragmentation : we believe 90% of it is due to lack of standards (domestic and international) and 10% to market fragmentation

Page 7 Legal elements….3 main building blocks

Transparency and information requirements ….The Directive will introduce clear and succinct information requirements …. Replacing 25 sets of national rules

It will be a difficult task The risk of different interpretations is high given the ambiguity and generality of certain provisions

Proportionality principle …..leaves maximum room for self regulation of industry

Self regulation by industry alone is dangerous. It is the “market” that must self regulate and the market comprises all stakeholders

Member states are allowed, where appropriate, to introduce national alternatives or keep practices that are currently more efficient than envisaged in the Directive

It is a very dangerous phrase. The Directive should set “basic principles”, valid in all Member States. If each Member State is entitled to be different, if more efficient, then how much

harmonization will the Directive achieve ?

How will this impact standardisation?

Preamble

(6) Some provisions should not apply to transactions above a certain amount since the user is likely to be in a position to negotiate more specific and more appropriate terms and conditions with the PSP See point 1 of our essential points

(7) It is necessary to specify the categories of PSP

The first three ones, credit and electronic money institutions and Post Office Giro institutions are already subject to community legislation.

A new 4th category “Payment Institutions” is introduced which must be given a single license to operate
Will Directive and Member States implementation add / substitute new norms to the existing legislation ?
In which category do credit Card companies fall?

(9) Criteria to define new rules for 4th category

Provisions of (9) applying to a new category are new and to be defined by member states
Who will define them in each state? Ministry of Finance? Central Bank?

(10) Member states must designate authorities responsible for granting authorization to payment institutions …..their tasks should be without prejudice to Eurosystem , which is responsible for the oversight of payment systems .

What does the ECB think about this?

Will this create different situations in Members States?

(11) It sets a derogation by member states “…payments providers unable to meet all those conditions may nevertheless be treated as payment institutions ..only valid in member state of registration “

Dangerous norm; refer to point 2 of essential points

(12), (13) New payment institution should be able to operate within or participate in payment systems …

New legislation needed ……clarify rules governing access to payment systems …Non discrimination from banks ….

What do PEACHs, Banks, SWIFT, CBI, ISABEL, ETEBAC have to say?

(15) “Payments above € 50.000 are excluded because.. not processed the same way..”

They are processed in the same way domestically. Different treatment applies to payments sent to the RTGS system because of urgency or, in some countries, of amount limits (much higher than EUR 50.000 ).

Cross border payments in SEPA will have the same treatment as domestic.

The only processing difference, today, is for euro cross border payments over 50.000 euro, due to still-existing mandatory BoP reporting (which is bound to change in the future)

Elsewhere in the Directive, the EUR 50.000 limit is mentioned as a way to exclude companies and to limit banks risks from the strict liability principle.
This limit was not present in 5th NLF Draft.

EACT does not agree with this logic; refer to point 1 of essential points

(18) “Info communicated in a standard manner”

It is an important statement. EACT has often asked for standardisation of information reported from banks and a common “structure” of bank charges. Actual bank charges are a competitive issue but more standardised and, therefore, more comparable conditions is a desirable objective

(22) “Allocation of losses in case of unauthorised payment transactions not applying to corporates exceeding micro enterprises …corporates are normally in a better position to assess the risk of fraud and take countervailing measures “
EACT does not accept this logic; refer to point 1 of essential points

(24) Banks should define “point of acceptance” for purposes of revocation

Definition of dates and work-cycles should be more clearly defined

See point 5 of essential points

(25) The full amount transferred by the payer should be credited to the payee…… charges must be debited separately….“Explicit” agreements of payee with payee bank to deduct charges are allowed.

The provision (all the above or only the explicit clause?) applies only if payments are:

1) in currency of a member state ( Euro in Euroland , £ in the UK ,etc )
2) where no currency exchange takes place ( in UK, a .£ payment to a £ account )
3) both PSP are based in the Community ( applies also to payments in $ , Yen etc ? )

Only the payee is mentioned; what about the amount debited to the payer?
Usually, when a treasurer is credited, he needs to see the full amount transferred to be able to reconcile the payment.

(26) Sharing of fees ….SHA but only if both Payment Service Providers are in the EU and there is no currency exchange …

As an example it does not apply if a UK bank pays from a GBP into a Euro account; same if the currency is $ or yen. In these cases the user can choose BEN or OUR

(27) Max execution time = 1 day

For payer-initiated payments …credit transfer and money remittances

By default also Direct Debit and cards …if no different explicit agreement Refer to point 5 of essential points

(29) No value dating to the disadvantage of the user

And to its advantage? Is float allowed?

Refer to point 6 of essential points

(30) “Strict Liability” on Payment Service Providers except…. Does not apply “ in full” when the PSP of the payee is outside the community ….

EACT approves the affirmation of the strict liability principle and thinks it should apply to all transactions and to all payment users Refer to point 1 of essential points

(31) Member states should not be allowed to require a particular identifier….

To which identifier does it refer? Account Owner? Bank and account? Transaction ID?

EACT agrees that identifiers should be standard and defined at EU level

Until there is a EU decision, Member States must be allowed to use current identifier. In particular, a Member State should be allowed to identify account owner by a code, like Tax ID, instead of text such as name and address.

The only bank /account identifier should be the IBAN …But IBAN is indicated as one, not the only choice
Refer to point 4 of essential points

(35) This Directive should be without prejudice to provisions of national law relating to the consequences as regards liability of inaccuracy in the expression or transmission of the bank statement “

This is a curious insert and the only reference in the Directive to the bank statement.

We do not agree; the Directive is a good opportunity to standardise national laws and banking rules in this important matter.

(38) More detailed rules are needed concerning the ….fraudulent use of cards…… distance contracts (e- commerce ? ) ……distance financial services

The three Directives should be amended accordingly

TITLE 1

Refer to essential points

Article 1

EACT requests to add to article 1:

SSC, Payment Factories and Group Treasury, handling transactions on accounts of group companies are not considered to be payment service providers.

Article 2

EACT requests to modify article 2

All transactions, whatever their amounts, are covered by Title III and IV.

Payment users, which are companies, can negotiate with payment service providers waivers to provisions of Titles III and IV.

Article 4

“unique identifier” …. Consists of the IBAN, BIC and name or account owner (the bank account is redundant if the IBAN is provided) and ,for card payments, a card number .

TITLE II

(Payments Institutions)

In addition to banks, the directive proposes a new category of payment service providers: payment institutions. We understand that the essential reason is to increase competition with a view to enhancing efficiency and achieving more competitive prices. Naturally, we are not opposed to such an objective, but we wish to draw the following points to your attention:

• The payment system must be secure. To achieve that objective, the banks which provide these services are today subject to a certain number of constraints. It will be necessary to ensure that payment institutions are subject to identical constraints, both as regards operational risks and own funds since they will have repayment obligations in the event of errors or unauthorised payments. This observation is motivated in particular by the preamble (point n° 11) which proposes that payment institutions that do not satisfy all the conditions for authorisation may, however, be considered as such by the Member State where they are registered. EACT considers that it is fundamental for the security of the SEPA, that no payment institution should be registered if it does not satisfy all the obligations attached to that status.
• The directive lays down certain criteria for the choice, by the Member States, of the authority responsible for supervising these payment institutions (article 15). As a duality of supervisory authorities would be a source of difficulties and additional costs, it would be judicious in our opinion that the same institution be in charge, in each country, of supervising banks in the area of payments as well as payment institutions and impose the same supervisory constraints to both.
  The preamble to the directive states that the implementation of the SEPA will lead to significant savings, but the necessary investments by both payments system providers and companies using the system do not seem to have been calculated and could be important. Furthermore, these savings will be accompanied – if we have properly understood the current SEPA projects – by a transfer of certain charges, in particular as regards verification, from payment service providers to users, irrespective of whether they are creditors or debtors. When the SEPA is established, these overall savings could therefore result in gains for certain parties involved in the payments

TITLE III

(Transparency of conditions for payment services)

Chapter 1. Single payment transactions

Is the distinction between single payment and payments under a framework contract so important to justify two separate chapters?

The reason may be the new Payment Service Providers who do not hold current accounts but only payment accounts that are used once without a framework contract

Member States are called upon to issue many delicate norms and regulations to implement Title III

Diversity of implementation should be avoided by guidelines and strict monitoring by the ECB and the Eurosystem

Article 25 Prior general information

1. Must be on paper or durable medium…

2. If payment is on “means of distant communication” ( e.g. Internet ) …PSP must comply with provision 1) as soon as possible …

Must send paper contract by mail ? Contract must be returned with signature ? Can use e mail ? User cannot download /print from Internet a valid confirmation of contract ? PSP cannot get user approval from Internet ?
The problem is that Digital Signature would be needed ,which the tipical user does not have .

Article 26 Communication of conditions

1 ( a )

( i ) Member states shall ensure communication of ….information or
unique identifier

Beneficiary’s name and address or unique identifier ( could not be
imposed by single state ….e.g. TAX ID in Italy as only reference )

Article 27 Information to payer after “acceptance”

( a ) … a reference for PSU to identify the payment transaction and , where
appropriate, the information relating to the Payee

In single payments there is no provision for information to be sent to the payer after execution …Vice versa , in framework contracts ( Article 36 ) there is no provision for information sent after acceptance ….

What is rationale ?

This article lists the same information of Article 36 ( see further) which refers to information provided after “execution”
Is this the information sent with the “explicit acceptance” which is required for electronic payments ? Today this kind of information is sent with the statement after transaction has been executed and booked .
Is the transaction reference indicated the one assigned by the payers bank…the reference sent by the payer or the reference assigned by the Clearing ?

We would ask that the information about the payee be always given on credit transfer .
See also point 7 of essential points

Article 28 Information available to the payee after receipts of funds

( a ) the reference of the payer and the information transferred with the payment
transaction enabling the payee to identify the payment transaction

The wording is ambiguous (see also General Observations)
“Reference of the payer” is either the Name and Address or Unique Identifier
“Information transferred “ …. Is either the “transaction ID “ ( it identifies the payment for track and tracing …) or the end-to-end ID assigned by the payer ( also called URI )

Chapter 2 . Framework Contracts

Almost all rules are the same as in single payments except …

Article 31 Communication of conditions

( b ) Obligations and liabilities
( ii ) execution and relevant “maximum time”
max. time not mentioned in single payment …

( v ) PSP can block a payment verification instrument if spending pattern suspicious

( c ) Spending ceilings

In case of aggregate fee … Split in components for transparency
Good objective but difficult to implement …

Article 32 Information to be provided after entry in force …about specific payment transactions
Could PSP not know about reporting obligations….declarations and tax issues before accepting payments ?

Article 33 Changes in contractual conditions

1. Not applied to Interest rates pegged to published market reference rate
What banks do in many countries ? Most C/C rates are not pegged …

Article 36 Information to payer after execution

Same wording as for single payment (see above comments)

( a ) Reference to identify payment
The one given by him or the one given by the bank for track and tracing ?

( c ) Fees or charges ….in case of aggregate fee … transparency…. Split for different
service level

Good idea but difficult to implement

Article 37 Information to payee after receipt of funds

Same wording as for single payment (see above comments)

TITLE IV

( Rights and obligations )

Chapter 1

( Authorisation of payment transactions)

Articles 41 , 42 Consent & transmission of consent

authorization to PSP must be explicit …if not….it’s an unauthorised transaction

A payment transaction may be authorised prior or “subsequent” to the execution “Subsequent” seems strange and an example would help clarify.In credit transfer, authorization after execution is not possible and in direct debit, the payer can block the debit before due date or ask for a refund afterwards but does not authorise payment after due date.. the debit is automatic.

An authorization to debit is present in certain electronic trade bills like RIBA, which is like a DD without a mandate and protects debtor who is asked by his bank to authorise the debit .

Payer may transmit consent using a payment verification instrument

Digital signature ? Other ? Why it is not said ?

Article 45 Unauthorised transaction and withdrawal of consent

1. When learning of irregularities from information provided by PSP ( Art 36 ) the Payer shall notify PSP without undue delay ..

2. In case of series of transactions ….authorization may be withdrawn …all subsequent transactions will be unauthorised without prejudice to irrevocability rule ( Art 56 ) …..

The payer learns of irregular transactions from bank statements.

So the frequency of bank statement is important (electronic statements are available daily) and the payer is responsible for checking them.

Time limit of request for refund should tick off from the date the statement is made available to the payer ( not when he reads it).

Article 49 PSP liability for losses of unauthorised payments

Further financial compensation may be determined according to the law applicable to the contract

We do not like the idea that national legislations may be different in this area

Article 50 User liability for losses of unauthorised transactions

Does not apply to corporates ( see Art 1 (3) (b) of Directive 2000/46/EC )

1. User’s liability before notification is limited to max. 150 Euro

Member states may reduce amount but only for PSP authorised in the state

We do not like the idea of differences in the EU. What happens to a payer using
PSP authorised in other state ?

Article 51 Micro-enterprises and electronic money

Refers to the previous two articles to exclude corporates and electronic money from their provisions

Article 52 Refunds

Direct Debit …. Member states shall ensure that payer will get refund when both…

1. Amount not specified in authorisation

2. Amount is not amount that a reasonable payer would expect if he were in the payer’s situation

It restricts to only these two cases the right to request a refund while the EPC Rulebook is more general .
The second case leaves ample room to subjective interpretations .

Article 53 Requests for refunds

1. Payer shall requests refund at the latest within 4 weeks of being informed of the payment transaction by PSP
Payer must present factual information to get refund ( Art. 52 )

2. PSP will pay within 10 day or contest

3. Corporates … PSP may agree on different time limits

1) It is a definite improvement vs. EPC Rulebook’s 3 months period .

2) The PSP that refunds is the PSP of the payer and he has 10 days refund as in the EPC
Rulebook . When the payee is debited is not said ; is it left to the banks to decide?

3) Does this refer only to the B2C or also the B2B case ?

The Payment Service User in question is the creditor ? The debtor ?

Chapter 2
( Execution of payment transactions )

Section 1
( Payment orders , fees and amounts transferred )

Article 54 Acceptance of orders (see point 5 of essential points)

1. Point in time of acceptance occurs when three conditions are met

( i ) Order received

( ii ) PSP completed authentication of the order, including a possible check on the
availability of funds

( iii ) PSP has explicitly or implicitly accepted order

In Credit transfer, how can the payer’s bank accept the order without checking availability of funds ?

In Direct Debit, the payee’ s bank cannot check debtor’s availability of funds

Point of acceptance no later than when PSP starts to execute

When does the PSP start to execute the order? For example when the order is sent to the clearer but not yet confirmed by the clearer?

2. In Electronic Payments, PSP shall inform user of acceptance …

Max D + end of 1 working day

( where D is point of time of acceptance )

Article 55 Refusal of payment orders (see essential points)

Agreed means of communication

When refused …reasons for refusal and , if possible, procedure for correcting factual mistakes that led to the refusal

For example.. give correct IBAN of beneficiary (Credit Transfer) or payer (Direct Debit)

Max. D + 3 wkg. days

Can refusal occur after execution time has expired ?

Can the PSP refuse the order before execution time expired ?

For e-payments …how to reconcile the fact that acceptance must be explicitly given before D + 1 and refusal before D + 3?

If PSU does not receive acceptance in D+1, does he conclude that his payment has been refused?

Article 56 Irrevocability of payment order

No revocation after Point of Acceptance ( CT: by Payer’s PSP DD: Payee’s PSP )

If payments orders are sent in advance with specific execution date in the future…. revocability date can be anticipated to within 3 wkg days preceding the point in time of acceptance

Why specify? Can’t one always revoke before the Point of Acceptance?

Are payment orders sent in advance with future execution date accepted earlier by PSP?

Section 2
( Execution time )

For all articles about Execution, see point 5 of essential points

Article 60 Credit transfer
Max D + 1 wkg day but up to 1/1/2010 …..max. D + 3 wkg days

Same as communication of acceptance in e-payments ..

PSP must communicate acceptance and execute before end of D+1 working day

But it can refuse until D + 3 working days ( ??? )

Article 61 Direct debit

Amount credited to payee = max. A + 1 wkg day…. unless otherwise explicitly agreed

No reference ever to acceptance date in the EPC Rulebook. D date is Due date

If payer’s PSP does not release funds until D + 5 (EPC Rule book), is the payer still debited on Due Date or date of release of funds ?

PSP ( payee’s… ) must inform payee if payer’s PSP does not release funds

This communication is not standardised ? It says agreed by the parties.

Article. 62 Absence of payee payment account with PSP

In this case, the money will be made available to him in same time
( CT and DD : D +1 wkg day )

How ? Communication to come and collect the money ?

Article 63 Cash deposits

If payment is made with cash deposited in account in D …Cash is credited max D+1

Is this what the provision says ?

Article 64 National Payment Transactions

For purely domestic transactions, member states may provide for shorter execution times

Shorter than D+3 is understandable , shorter than D+ 1 is more difficult

Section 3
(Availability of funds and liability )

Article 65 Availability of funds on a payment account

The gist of this article seems to be that the banks can take no float …debtor and creditor book and value date is the same …

But is it really so ?

Article 66 Incorrect unique identifiers see also point 4 of essential points

1. If unique identifier is used … PSP will execute correctly only based on IBAN

Where IBAN is used as unique identifier …. It should take precedence over the name of the payee if provided. However, PSP should , where possible, verify consistency of the two

EACT does not agree and believes that it should be mandatory for banks to check the name or, better ,the digital identity of account owner ( EACT has proposes to define ,country by country which unique code can be used to identify business and individual counterparts .This unique code will also be used for Digital Identity )

Why cite IBAN as one of possible unique identifiers? The EC does not believe that by 2010 BBAN will be substituted by IBAN in domestic payments?

BIC is not mentioned

2. If unique identifier supplied by user is not correct , PSP is not liable for non- or
defective execution …

However… , PSP will make a “bone fide” effort to recover the funds…

See EACT’s above proposal

3. Additional info provided by user in addition to what is in Communication for Conditions
by PSP ( see Art. 26 ) PSP is liable only for execution in accordance with unique
execution

What is this “additional information” ? Name ? Transaction identifier ?

Article 67 Non execution or defective execution

1. Strict liability after point of acceptance ( PoA )

For e-paymentsis it the PoA or communication of PoA ???