مبدأ الموافقة الصريحة

04 — مبدأ الموافقة الصريحة

الحالة: مبدأ حاكم أساسي

النطاق: منظومة بال لانسر، والعقود، وعروض الأسعار، ومسودات العقود، والملاحق، والتعديلات، والإقرارات، والموافقات، والإجراءات والقرارات التي تتطلب قبولًا أو إذنًا من المستخدم داخل المنظومة.

أولًا: نص المبدأ

لا يجوز إنشاء التزام تعاقدي أو تعديل التزام قائم أو ترتيب أثر قانوني أو تشغيلي على المستخدم من خلال منظومة بال لانسر، متى كان ذلك الأثر يتطلب موافقته، إلا بعد صدور موافقة واضحة وصريحة منه على الإجراء أو المستند أو الشروط ذات الصلة.

ويجب أن تكون الموافقة مرتبطة بمحل محدد ومعلوم للمستخدم، وأن تصدر بعد إتاحة المعلومات الجوهرية اللازمة لفهم طبيعة ما يوافق عليه وآثاره الأساسية.

ولا يُعد السكوت أو عدم الرد أو استمرار استخدام المنظومة، بذاته، موافقة صريحة على إنشاء عقد أو قبول عرض سعر أو تعديل التزام جوهري، ما لم يقرر القانون واجب التطبيق خلاف ذلك في حالة محددة.

ولا يجوز استخلاص موافقة ملزمة من مجرد سلوك تقني أو تفاعل داخل المنظومة لا يدل بوضوح على إرادة المستخدم في إنشاء الأثر القانوني أو التعاقدي المعني.

ثانيًا: شروط صحة الموافقة داخل المنظومة

لأغراض منظومة بال لانسر، يجب أن تكون الموافقة، بحسب طبيعة الإجراء والمتطلبات واجبة التطبيق:

1. صادرة عن المستخدم أو عمن يملك صلاحية قانونية أو تفويضًا صحيحًا بالتصرف نيابة عنه.
2. واضحة ومحددة بالنسبة إلى الإجراء أو المستند محل الموافقة.
3. مسبوقة بإتاحة المعلومات والشروط الجوهرية المتعلقة بما تتم الموافقة عليه.
4. صادرة من خلال إجراء إيجابي يدل بصورة واضحة على إرادة المستخدم.
5. مرتبطة بالمستند أو النسخة أو الإجراء المحدد الذي صدرت بشأنه.
6. قابلة للتوثيق والإثبات بالوسائل التقنية والسجلات المعتمدة داخل المنظومة.
7. غير ناتجة عن تصميم مضلل أو إخفاء متعمد لمعلومة جوهرية من شأنها التأثير في قرار المستخدم.

ولا يغني مجرد وجود شرط أو مستند داخل المنظومة عن إثبات قبول المستخدم له عندما تكون موافقته مطلوبة.

ثالثًا: عرض السعر ومسودة العقد قبل الالتزام النهائي

لا يُعد إعداد عرض السعر أو إرساله أو عرضه داخل المنظومة، بذاته، عقدًا نهائيًا أو قبولًا ملزمًا من الطرف الموجه إليه، ما لم تستكمل إجراءات الموافقة والتعاقد المعتمدة.

وقبل ترتيب أي التزام تعاقدي نهائي على قبول عرض السعر، يجب أن تتاح للطرف المعني فرصة مناسبة للاطلاع على عرض السعر ومسودة العقد أو المستند التعاقدي المرتبط به.

ويجب أن تتضمن الحزمة المعروضة، بحسب طبيعة المعاملة، العناصر الجوهرية اللازمة لفهم الالتزام، بما في ذلك:

1. هوية وصفة أطراف المعاملة.
2. نطاق العمل أو الخدمة.
3. المخرجات المطلوبة.
4. المراحل، إن وجدت.
5. القيمة والمبالغ المرتبطة بالمراحل.
6. المدد والمواعيد.
7. شروط التنفيذ.
8. شروط التسليم والقبول والرفض.
9. الأحكام المتعلقة بالتعديل أو الإلغاء أو الانسحاب أو الإنهاء بحسب الحالة.
10. الأحكام الجوهرية المتعلقة بالحقوق والالتزامات والملكية الفكرية والنزاعات وغيرها بحسب طبيعة المعاملة.

ويجب أن تستند مسودة العقد إلى البيانات والشروط التي تم التوصل إليها أو اعتمادها خلال مسار المعاملة، وألا تتضمن التزامًا جوهريًا جديدًا لم يُعرض بصورة واضحة على الطرف الذي سيتحمل ذلك الالتزام.

ويجوز للأطراف، قبل الموافقة النهائية، طلب تعديل العناصر القابلة للتفاوض.

ولا يصبح أي تعديل جزءًا من الاتفاق إلا بعد اعتماده من الطرف أو الأطراف التي تتأثر حقوقها أو التزاماتها به وإدراجه في النسخة المحدثة ذات الصلة.

ولا يجوز اعتبار موافقة تجارية سابقة، أو موافقة على السعر وحده، أو على عنصر منفرد من عناصر العرض، موافقة تلقائية على شروط تعاقدية جوهرية لم تكن معروضة على الطرف وقت إصدار تلك الموافقة.

رابعًا: الموافقة النهائية وتكوين العقد

يجب أن تتاح للأطراف، قبل إصدار الموافقة النهائية، فرصة مناسبة لمراجعة النسخة النهائية من عرض السعر والعقد أو المستند التعاقدي المرتبط به.

ويجب أن ترتبط الموافقة النهائية بالنسخة المحددة التي عُرضت على المستخدم، بحيث يمكن لاحقًا تحديد المستند والشروط التي وافق عليها.

ولا يجوز تعديل النسخة التي تمت الموافقة عليها تعديلًا جوهريًا ثم اعتبار الموافقة السابقة ممتدة تلقائيًا إلى النسخة المعدلة.

وعند إجراء تعديل جوهري بعد عرض النسخة على الأطراف، يجب إظهار التعديل للطرف أو الأطراف المتأثرة وإتاحة النسخة المحدثة لهم والحصول على الموافقة الجديدة اللازمة قبل ترتيب أثر التعديل.

ويصبح العقد نافذًا وفق آلية التعاقد المعتمدة بعد اكتمال الموافقات المطلوبة واستيفاء المتطلبات القانونية والتعاقدية اللازمة لنفاذه.

ولا يعني نفاذ العقد، بذاته، أن العملية المالية قد تمت أو أن المستخدم أصدر التفويض المالي اللازم لها.

خامسًا: الموافقة على المراحل والتعديلات

عندما يكون المشروع أو الخدمة مقسمًا إلى مراحل، لا يجوز استخدام موافقة المستخدم على مرحلة معينة باعتبارها موافقة تلقائية على تعديل جوهري في مرحلة أخرى أو على إضافة أعمال أو تكاليف لم تكن مشمولة في الاتفاق المعتمد.

وأي تعديل جوهري في نطاق العمل أو المخرجات أو القيمة أو المواعيد أو شروط التنفيذ يجب توثيقه وفق الآلية المعتمدة والحصول على موافقة الطرف أو الأطراف التي تتأثر حقوقها أو التزاماتها بذلك التعديل.

ويجب أن تنعكس التعديلات الجوهرية المعتمدة على المستندات التعاقدية ذات الصلة بحيث تظل النسخة النافذة قابلة للتحديد والإثبات.

ولا يمنع ذلك من تطبيق التغييرات التشغيلية غير الجوهرية التي يسمح بها العقد أو السياسة ولا تؤدي إلى تغيير جوهري في حقوق الأطراف أو التزاماتهم.

ولا يحول هذا المبدأ دون تنظيم مدد إجرائية للرد أو المراجعة في العقود أو السياسات المتخصصة، شريطة ألا يُرتب على انقضائها اعتبار السكوت موافقة صريحة أو قبولًا تعاقديًا إلا إذا كان ذلك جائزًا قانونًا ومقررًا بوضوح في الوثيقة الحاكمة للمعاملة.

سادسًا: الموافقة والإجراءات المالية

لا يجوز اعتبار إنشاء عقد أو قبول عرض سعر أو تسجيل استحقاق داخل بال لانسر، بذاته، تفويضًا مفتوحًا للمنظومة بتنفيذ خدمة مالية خاضعة للترخيص.

وعندما يتطلب الإجراء المالي موافقة أو تفويضًا من المستخدم، يجب الحصول عليه وفق الآلية والمتطلبات التي تطبقها الجهة المالية المرخصة والقانون واجب التطبيق.

ولا يجوز لبال لانسر إنشاء أو افتراض موافقة مالية نيابة عن المستخدم خارج نطاق الصلاحيات الممنوحة لها قانونًا وتعاقديًا.

ويجب الفصل بين:

الموافقة على عرض السعر، والموافقة والتوقيع على العقد داخل بال لانسر، والتفويض أو الموافقة اللازمة لتنفيذ العملية المالية لدى البنك أو مزود خدمات الدفع أو الجهة المالية المرخصة.

ولا يعني تحقق أحد هذه الإجراءات تحقق الإجراءات الأخرى تلقائيًا.

سابعًا: الموافقة واستخدام الذكاء الاصطناعي

يجوز استخدام تقنيات الذكاء الاصطناعي لتحليل المحادثات بين الأطراف، واستخراج عناصر الاتفاق، والكشف عن العناصر الناقصة أو المتعارضة، وتلخيص ما تم التوصل إليه، والمساعدة في إعداد عرض السعر ومسودة العقد أو التعديل وفق القواعد والقوالب المعتمدة.

ولا يجوز اعتبار ما يستنتجه الذكاء الاصطناعي من المحادثة موافقة صريحة من أي طرف.

ولا يجوز للذكاء الاصطناعي:

1. إصدار الموافقة نيابة عن المستخدم.
2. اعتبار اقتراح لم يرد عليه المستخدم مقبولًا.
3. فرض سعر أو نطاق عمل أو مدة أو شرط تعاقدي لم يعتمده الأطراف.
4. إنشاء التزام جوهري استنادًا إلى استنتاج احتمالي عن نية المستخدم.
5. تحويل عنصر غير محسوم أو متعارض في المحادثة إلى شرط تعاقدي نهائي دون تأكيده.

وعندما يستخلص النظام عناصر يرى أنها محل اتفاق، يجب إدراجها في عرض السعر ومسودة العقد أو المستند التعاقدي المناسب وعرض العناصر التي تتطلب موافقة ملزمة على الأطراف قبل ترتيب أثر قانوني أو تعاقدي عليها.

ويظل دور الذكاء الاصطناعي مساعدًا في التحليل والصياغة والتنظيم، ولا يحل محل إرادة الأطراف أو الموافقات المطلوبة منهم.

ثامنًا: توثيق الموافقة وإثباتها والتوقيع الإلكتروني

يجب أن تسمح المنظومة، بالقدر المناسب لطبيعة الإجراء والمتطلبات واجبة التطبيق، بتوثيق الموافقات التي يترتب عليها أثر قانوني أو تعاقدي.

ويجوز أن تشكل وسيلة الموافقة أو التوقيع المستخدمة داخل المنظومة توقيعًا إلكترونيًا ذا أثر قانوني متى استوفت المتطلبات والشروط المقررة بموجب القانون واجب التطبيق.

ولا يُفترض أن كل إجراء إلكتروني أو نقرة أو سجل تقني يشكل بذاته توقيعًا إلكترونيًا صحيحًا قانونًا ما لم تتحقق المتطلبات القانونية اللازمة بحسب طبيعة الإجراء والمعاملة.

ويجوز أن تشمل سجلات التوثيق، بحسب الحاجة والمشروعية:

1. هوية الحساب الذي أصدر الموافقة.
2. صفة الشخص أو صلاحية ممثل الجهة عند الاقتضاء.
3. المستند والنسخة المحددة التي تمت الموافقة عليها.
4. تاريخ ووقت الموافقة.
5. الإجراء الإلكتروني المستخدم لإصدارها.
6. أي بيانات تقنية أخرى يكون الاحتفاظ بها مشروعًا وضروريًا لإثبات الموافقة وسلامة المعاملة.

ويجب حماية سجلات الموافقة من التعديل غير المصرح به، والاحتفاظ بها وفق القانون والسياسات ومتطلبات الاحتفاظ بالبيانات واجبة التطبيق.

ولا يجوز جمع بيانات لإثبات الموافقة تتجاوز ما يكون ضروريًا ومتناسبًا مع الغرض المشروع من التوثيق.

تاسعًا: سحب الموافقة وحدوده

عندما يسمح القانون أو طبيعة الموافقة بسحبها، يجب توفير وسيلة مناسبة لذلك وفق السياسة والمتطلبات واجبة التطبيق.

ولا يؤدي سحب الموافقة، بذاته، إلى إلغاء الآثار القانونية التي ترتبت بصورة صحيحة قبل السحب، متى كانت تلك الآثار قائمة على موافقة صحيحة أو على أساس قانوني آخر.

ولا يجوز استخدام مفهوم سحب الموافقة باعتباره حقًا مطلقًا في إلغاء عقد نافذ أو التهرب من التزام تعاقدي قائم.

وتخضع حالات الإلغاء والانسحاب والإنهاء والاسترداد لأحكام العقد والسياسات والقانون واجب التطبيق.

ويجب التمييز بين سحب موافقة قابلة للسحب وبين إنهاء أو إلغاء التزام تعاقدي سبق تكوينه بصورة صحيحة.

عاشرًا: الموافقة على الشروط والسياسات وتعديلاتها

يجب عرض الشروط والسياسات التي تتطلب موافقة المستخدم بطريقة تمكنه من الاطلاع عليها قبل إصدار الموافقة.

وعندما يطرأ تعديل جوهري يؤثر في حقوق المستخدم أو التزاماته، يجب التعامل معه وفق متطلبات الإشعار والموافقة التي يفرضها القانون أو العقد بحسب الحالة.

ولا يجوز افتراض أن الموافقة السابقة تشمل تلقائيًا أي تعديل جوهري لاحق عندما تكون موافقة جديدة مطلوبة قانونًا أو تعاقديًا.

ويجب الاحتفاظ، بالقدر اللازم والمشروع، بإمكانية تحديد النسخة التي كانت نافذة أو التي وافق عليها المستخدم في الوقت ذي الصلة.

الحادي عشر: منع الموافقة المضللة أو القسرية

يجب ألا تُصمم واجهات أو إجراءات الموافقة بطريقة تهدف إلى تضليل المستخدم أو دفعه إلى الموافقة على أمر لم يكن يقصده بصورة معقولة.

ويجب تمييز الإجراء الذي ينشئ التزامًا جوهريًا عن الإجراءات التشغيلية العادية بالقدر المناسب لطبيعة المعاملة.

ولا يجوز إخفاء شرط جوهري أو عرضه بطريقة من شأنها أن تمنع المستخدم بصورة غير معقولة من إدراك أثر موافقته.

ولا يجوز تصميم مسار المستخدم بحيث يكون رفض شرط اختياري أو الرجوع عنه أصعب بصورة غير مبررة من قبوله عندما تقتضي القواعد واجبة التطبيق خلاف ذلك.

ولا يمنع ذلك المنظومة من اشتراط قبول شروط لازمة ومشروعة لاستخدام خدمة معينة، متى كان ذلك واضحًا ومتوافقًا مع القانون.

04 — PRINCIPLE OF EXPLICIT CONSENT

Status: Fundamental Governing Principle

Scope: The PalLancer ecosystem, contracts, quotations, draft contracts, addenda, amendments, declarations, consents, procedures, and decisions requiring acceptance or authorization by a user within the ecosystem.

1. Principle

No contractual obligation may be created, no existing obligation may be amended, and no legal or operational effect may be imposed upon a user through the PalLancer ecosystem where such effect requires the user's consent, unless the user has given clear and explicit consent to the relevant action, document, or terms.

Consent shall relate to a specific and identifiable subject matter and shall be given only after the user has been provided with the material information necessary to understand the nature of the matter being consented to and its principal effects.

Silence, failure to respond, or continued use of the ecosystem shall not, in and of itself, constitute explicit consent to enter into a contract, accept a quotation, or amend a material obligation, unless otherwise provided by applicable law in a specific case.

Binding consent shall not be inferred merely from technical conduct or interaction within the ecosystem that does not clearly demonstrate the user's intention to create the relevant legal or contractual effect.

2. Requirements for Valid Consent Within the Ecosystem

For the purposes of the PalLancer ecosystem, consent shall, according to the nature of the relevant action and applicable requirements:

1. Be given by the user or by a person possessing valid legal authority or authorization to act on the user's behalf.
2. Be clear and specific in relation to the action or document to which the consent applies.
3. Be preceded by access to the material information and terms relating to the matter being consented to.
4. Be expressed through an affirmative action that clearly demonstrates the user's intention.
5. Be linked to the specific document, version, or action to which it relates.
6. Be capable of being documented and evidenced through the technical means and records approved within the ecosystem.
7. Not result from misleading design or the intentional concealment of material information that could affect the user's decision.

The mere presence of a term or document within the ecosystem shall not substitute for evidence of the user's acceptance where the user's consent is required.

3. Quotation and Draft Contract Prior to Final Commitment

The preparation, transmission, or presentation of a quotation within the ecosystem shall not, in and of itself, constitute a final contract or binding acceptance by the recipient unless the approved consent and contracting procedures have been completed.

Before acceptance of a quotation gives rise to any final contractual obligation, the relevant party shall be provided with an appropriate opportunity to review the quotation together with the draft contract or associated contractual document.

Depending on the nature of the transaction, the package presented shall contain the material elements necessary to understand the proposed obligation, including:

1. The identity and capacity of the parties to the transaction.
2. The scope of work or service.
3. The required deliverables.
4. The milestones, where applicable.
5. The price and amounts associated with the relevant milestones.
6. The applicable periods and deadlines.
7. The performance terms.
8. The delivery, acceptance, and rejection terms.
9. The applicable provisions concerning amendment, cancellation, withdrawal, or termination, as appropriate.
10. Material provisions relating to rights and obligations, intellectual property, disputes, and other matters relevant to the nature of the transaction.

The draft contract shall be based on the data and terms reached or approved during the transaction process and shall not contain any new material obligation that has not been clearly presented to the party who would be subject to that obligation.

Before final consent, the parties may request amendments to negotiable elements.

No amendment shall form part of the agreement unless it has been approved by the party or parties whose rights or obligations are affected by it and incorporated into the relevant updated version.

Prior commercial approval, approval of the price alone, or approval of an individual element of a quotation shall not constitute automatic consent to material contractual terms that were not presented to the relevant party at the time such approval was given.

4. Final Consent and Contract Formation

Before giving final consent, the parties shall be provided with an appropriate opportunity to review the final version of the quotation and the contract or associated contractual document.

Final consent shall be linked to the specific version presented to the user so that the document and terms to which the user consented can subsequently be identified.

A version that has already been approved shall not be materially amended and the prior consent then treated as automatically extending to the amended version.

Where a material amendment is made after a version has been presented to the parties, the amendment shall be disclosed to the affected party or parties, the updated version shall be made available to them, and any required new consent shall be obtained before the amendment takes effect.

The contract shall become effective in accordance with the approved contracting mechanism once all required consents have been obtained and all legal and contractual requirements necessary for its effectiveness have been satisfied.

The effectiveness of the contract shall not, in and of itself, mean that the financial transaction has been completed or that the user has provided the financial authorization required for such transaction.

5. Consent Relating to Milestones and Amendments

Where a project or service is divided into milestones, a user's consent to a particular milestone shall not be treated as automatic consent to a material amendment to another milestone or to the addition of work or costs that were not included in the approved agreement.

Any material amendment to the scope of work, deliverables, price, deadlines, or performance terms shall be documented through the approved mechanism, and consent shall be obtained from the party or parties whose rights or obligations are affected by such amendment.

Approved material amendments shall be reflected in the relevant contractual documents so that the effective version remains identifiable and capable of being evidenced.

This shall not prevent the implementation of non-material operational changes permitted under the contract or applicable policy that do not materially alter the rights or obligations of the parties.

This Principle shall not prevent contracts or specialized policies from establishing procedural periods for response or review, provided that the expiry of such periods shall not cause silence to be treated as explicit consent or contractual acceptance unless such treatment is legally permissible and clearly established in the document governing the transaction.

6. Consent and Financial Procedures

The creation of a contract, acceptance of a quotation, or recording of an entitlement within PalLancer shall not, in and of itself, constitute an open authorization for the ecosystem to perform any financial service subject to licensing.

Where a financial action requires the user's consent or authorization, such consent or authorization shall be obtained in accordance with the mechanism and requirements applied by the licensed financial entity and applicable law.

PalLancer shall not create or presume financial consent on behalf of a user beyond the authority granted to it by law and contract.

A clear distinction shall be maintained between:

acceptance of the quotation, consent to and execution of the contract within PalLancer, and the authorization or consent required to execute the financial transaction through the bank, payment service provider, or other licensed financial entity.

Completion of any one of these actions shall not automatically constitute completion of the others.

7. Consent and the Use of Artificial Intelligence

Artificial intelligence technologies may be used to analyze communications between the parties, extract elements of their agreement, identify missing or conflicting elements, summarize matters reached between them, and assist in preparing the quotation, draft contract, or amendment in accordance with approved rules and templates.

Nothing inferred by artificial intelligence from the parties' communications shall constitute explicit consent by either party.

Artificial intelligence shall not:

1. Give consent on behalf of a user.
2. Treat a proposal to which the user has not responded as accepted.
3. Impose a price, scope of work, duration, or contractual term that has not been approved by the parties.
4. Create a material obligation based on a probabilistic inference concerning a user's intention.
5. Convert an unresolved or conflicting element in the parties' communications into a final contractual term without confirmation.

Where the system extracts elements that it identifies as matters agreed between the parties, those elements shall be incorporated into the quotation and draft contract or other appropriate contractual document, and any elements requiring binding consent shall be presented to the parties before any legal or contractual effect is attributed to them.

The role of artificial intelligence shall remain limited to assistance with analysis, drafting, and organization and shall not replace the parties' intent or the consents required from them.

8. Documentation and Evidence of Consent and Electronic Signatures

The ecosystem shall, to the extent appropriate to the nature of the relevant action and applicable requirements, enable the documentation of consents that produce legal or contractual effects.

A method of consent or signature used within the ecosystem may constitute an electronic signature having legal effect where it satisfies the requirements and conditions prescribed by applicable law.

No electronic action, click, or technical record shall automatically be presumed to constitute a legally valid electronic signature unless the applicable legal requirements have been satisfied, taking into account the nature of the action and transaction.

Documentation records may, where necessary and lawful, include:

1. The identity of the account through which consent was given.
2. The capacity or authority of the person representing an entity, where applicable.
3. The specific document and version that was approved.
4. The date and time of consent.
5. The electronic action used to provide consent.
6. Any other technical data whose retention is lawful and necessary to evidence consent and preserve the integrity of the transaction.

Consent records shall be protected against unauthorized alteration and retained in accordance with applicable law, policies, and data-retention requirements.

Data collected for the purpose of evidencing consent shall not exceed what is necessary and proportionate to the legitimate purpose of such documentation.

9. Withdrawal of Consent and Its Limitations

Where applicable law or the nature of the consent permits its withdrawal, an appropriate mechanism for withdrawal shall be provided in accordance with the applicable policy and requirements.

Withdrawal of consent shall not, in and of itself, invalidate legal effects that were validly created before such withdrawal where those effects were based on valid consent or another lawful basis.

Withdrawal of consent shall not be used as an absolute right to cancel an effective contract or evade an existing contractual obligation.

Cancellation, withdrawal from a transaction, termination, and refunds shall be governed by the relevant contract, policies, and applicable law.

A distinction shall be maintained between the withdrawal of consent that is legally capable of being withdrawn and the termination or cancellation of a contractual obligation that was validly formed.

10. Consent to Terms, Policies, and Amendments

Terms and policies requiring user consent shall be presented in a manner that enables the user to review them before giving consent.

Where a material amendment affects a user's rights or obligations, it shall be handled in accordance with the notice and consent requirements imposed by applicable law or contract, as the case may be.

Prior consent shall not be presumed to extend automatically to a subsequent material amendment where new consent is legally or contractually required.

To the extent necessary and lawful, the ecosystem shall maintain the ability to identify the version that was effective or accepted by the user at the relevant time.

11. Prevention of Misleading or Coercive Consent

Consent interfaces and procedures shall not be designed to mislead users or induce them to consent to something they could not reasonably be understood to have intended.

An action that creates a material obligation shall be appropriately distinguished from ordinary operational actions according to the nature of the transaction.

No material term shall be concealed or presented in a manner that unreasonably prevents the user from understanding the effect of giving consent.

The user journey shall not be designed so that rejecting or withdrawing from an optional term is unjustifiably more difficult than accepting it where applicable rules require otherwise.

Nothing in this provision shall prevent the ecosystem from requiring acceptance of lawful and necessary terms for access to a particular service, provided that such requirement is clearly disclosed and complies with applicable law.

12. Effect of the Principle of Explicit Consent

The Principle of Explicit Consent constitutes one of the governing principles of the PalLancer ecosystem and shall be observed in the design and operation of:

contracts, quotations, draft contracts, addenda, amendments, electronic consents, user interfaces, contracting workflows, payment procedures associated with transactions, the use of artificial intelligence, and software functions that create or modify rights or obligations.

This Principle shall be interpreted in conjunction with the Rule of Law Principle, the Compliance Principle, the Principle of Neutrality, and the other governing principles.

No technical or automated function within PalLancer shall substitute for user consent where such consent is legally or contractually required.

The technical design of the ecosystem shall also reflect the separation between artificial intelligence analysis, preparation of the quotation and draft contract, review, final contractual consent, and the financial procedure conducted through the licensed financial entity, so that a technical event occurring at one stage shall not automatically be treated as a substitute for a separate legal or financial event required at another stage.